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ABSTRACT 


The  purpose  of  this  thesis  is  to  provide  a  process  model  to  assist  organizations  in  analyzing  their 
Wide  Area  Network  communication  lines.  The  Naval  Medical  Information  Management  Center 
(NMIMC),  in  Bethesda,  Maryland,  is  used  as  the  model  site,  due  to  its  imminent  deployment  of  World 
Wide  Web  (WWW)  servers  to  Navy  Medical  Treatment  Facilities  (MTF’s).  To  model  the  typical  MTF, 
an  analysis  of  the  data  traffic  transmitted  from  the  existing  WAN  links  managed  and  monitored  by 
NMIMC  will  be  performed.  These  WAN  links  are  critical  for  the  delivery  of  health  care  related 
information  transmitted  between  MTF’s.  The  WAN  links  must  be  analyzed  to  ensure  that  adequate 
bandwidth  is  available  to  allow  unobstructed  traffic  flow  between  destinations.  The  data  traffic  will  be 
plotted  to  illustrate  problematic  conditions  caused  by  high  utilization  rates.  Corrective  actions  will  be 
recommended  that  should  help  to  reduce  or  eliminate  the  bottlenecks  and  increase  network  bandwidth, 
such  as:  load  balancing,  rightsizing  of  the  WAN  links,  and  increasing  operational  availability.  The 
hypothesis  is  that  the  WWW  servers  should  be  installed  after  the  WAN  links  are  analyzed  and  either 
balanced  or  properly  sized.  The  load  balancing  and  rightsizing  of  the  WAN  links  will  ensure  that 
adequate  bandwidth  is  available  for  the  proper  and  timely  transmission  and  access  of  vital  WWW  server 
information. 
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1.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  research  is  to  provide  a  process  model  to  assist  organizations, 
whether  military  or  civilian,  in  analyzing  their  Wide  Area  Network  (WAN)  communication 
links.  The  main  goal  of  this  study  is  to  ensure  that  proper  bandwidth  requirements  are 
firmly  incorporated  prior  to  implementing  a  new  network  server  into  an  existing  network. 

The  initial  intention  of  this  study  was  to  assist  the  Naval  Medical  Information 
Management  Center  (NMIMC),  located  in  Bethesda,  Maryland,  in  developing 
implementation  and  deployment  plans  for  their  World  Wide  Web  (WWW)  servers.  These 
servers  are  scheduled  for  deployment  to  Naval  Medical  Treatment  Facilities  (MTF),  as 
directed  by  the  Assistant  Secretary  of  Defense,  Health  Affairs  (ASD/HA).  These 
directives  are  discussed  in  the  background  section  below.  However,  upon  further 
investigation,  it  became  apparent  that  the  main  problem  to  be  encountered  with  this 
initiative  would  be  network  data-trafBc  bottlenecks  and  how  to  identify,  reduce,  or 
eliminate  them.  The  analysis  of  NMIMC’ s  WAN  links  will  model  a  typical  Navy  MTF. 

Therefore,  the  focal  point  of  this  thesis  is  to  analyze  the  primary  WAN  links 
emanating  from  NMIMC.  The  data  traffic  will  be  plotted  to  illustrate  problematic 
scenarios  caused  by  high  utilization  rates.  Recommendations  offered  to  correct  those 
problems  will  include  corrective  actions  that  will  help  balance  the  network  traffic  loads, 
and  methods  of  rightsizing  the  WAN  links.  Various  telecommunications  services  currently 
available  in  today’s  marketplace  will  be  also  be  addressed. 
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B.  OBJECTIVES  AND  SCOPE 


This  thesis  will  focus  on  analyzing  NMIMC’s  existing  WAN  links  and  the 
associated  network  data-trafiSc.  The  purpose  of  this  analysis  is  to  identify  interesting 
trends,  and  to  pinpoint  distinct  problems  associated  with  the  transmission  of  data.  Specific 
issues  such  as  the  timing  of  transmission  bursts  and  network  traffic  load  will  be 
researched.  Some  of  these  issues  are  greatly  influenced  by  traffic  congestion.  The  cause  of 
the  congestion,  also  known  as  a  bottleneck,  will  be  investigated.  Certain  problem 
resolutions  will  be  presented  to  assist  in  reducing  or  eliminating  these  bottlenecks,  and 
fi’eeing  up  precious  network  bandwidth. 

The  hypothesis  is  that  the  WWW  servers  should  be  installed  only  after  the  WAN 
links  are  analyzed  and  properly  sized.  The  rightsizing  of  the  WAN  links  will  ensure  that 
adequate  bandwidth  is  available  for  the  proper  and  timely  distribution  and  access  of 
WWW  server  information. 

C.  BACKGROUND 

1.  Health  Affairs  Directives 

Information  management  at  naval  MTF’s  is  becoming  increasingly  important.  To 
provide  enhanced  electronic  information  interchange  within  the  Military  Health  Support 
System  (MHSS),  the  Assistant  Secretary  of  Defense  for  Health  Affairs  (ASD/HA)  has 
initiated  directives  and  guidelines  for  implementing  a  global  information  system  utilizing 
the  internet  and  the  WWW.  [Ref  1] 
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In  support  of  this  initiative,  HA  has  agreed  to  fund  the  implementation  and 
operation  of  a  HA  IntemetAVeb  server,  including  hardware,  software,  contractor  support 
regarding  deployment  issues,  first  year  maintenance,  and  first  year  connectivity  (T-1 
access  to  the  internet).  Funds  will  be  transferred  from  HA  to  the  three  Services.  Each 
Service  then  assumes  the  responsibility  of  fimding  the  implementation  and  operation  of 
IntemetAVeb  servers  to  support  the  electronic  information  interchange  and  web  home 
pages  that  will  allow  complete  interoperability  across  Health  Affairs,  the  Surgeons 
General,  and  MTF’s.  Life  cycle  management,  as  well  as  fimding  for  continued 
maintenance  and  internet  access  for  the  out-years,  will  be  performed  and  provided  by 
NMIMC.  [Ref  2] 

2.  Requirements 

Per  HA  directives,  the  requirements  for  implementing  WWW  servers  to  DoD 
agencies  have  been  set  [Ref  1].  Each  agency,  or  service,  is  responsible  for  their 
implementation  and  deployment  plans.  The  Naval  Bureau  of  Medicine  and  Surgery 
(BUMED)  has  set  the  requirements  for  the  Navy’s  WWW  Enhanced  Electronic 
Information  Interchange  System,  and  has  tasked  NMIMC  with  the  implementation  and 
deployment  plans  [Ref  2].  More  detailed  information  surrounding  this  request  may  be 
found  in  Appendix  A. 

NMIMC  was  established  to  design,  deploy,  and  support  naval  medical  information 
management  systems  and  telecommunications  infrastructures.  Therefore,  the  inherent 
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nature  of  NMIMC  makes  it  uniquely  qualified  for  the  assigned  task  of  deploying  the 
Navy’s  WWW  servers. 

Questions  revolving  around  the  current  and  target  infrastructure  design,  load 
balancing,  WAN  connectivity,  bandwidth  requirements,  deployment,  training,  support,  and 
maintenance  are  Still  unresolved.  The  results  of  this  research  may  assist  in  answering  some 
of  these  questions  and  in  formalizing  the  plans  required  to  successfully  deploy  and 
implement  this  critical  medical  information  requirement. 
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II.  DATA  COLLECTION  AND  CONVERSION 


A.  PROBLEM  DEFmmON 
1.  NMIMC  Site  Visit 

A  briefing  between  the  author  and  key  management  personnel  of  NMIMC  took 
place  in  an  effort  to  arrive  at  the  true  nature  of  the  problem  surrounding  the  deployment  of 
the  WWW  servers  in  support  of  the  HA  initiatives.  In-depth  discussions  over  the  course 
of  several  days  revealed  the  urgent  requirement  of  ensuring  proper  bandwidth  for  the 
transmission  of  healthcare  related  data.  The  discussion  quickly  evolved  into  a  WAN  link 
capacity  planning  meeting.  Existing  WAN  link  capacity  charts  were  reviewed,  and 
recommendations  for  analyzing  the  links  out  of  NMIMC  were  made.  [Ref  3] 

The  discussion  then  turned  to  the  issue  of  how  to  estimate  the  growth  pattern  of 
the  network  traffic  due  to  the  installation  of  the  WWW  servers.  While  several  good  ideas 
were  proposed,  the  discussion  eventually  became  a  stalemate,  as  no  accurate  methods  of 
forecasting  and  projecting  the  growth  pattern  of  network  traffic  were  readily  known. 

The  nature  of  traffic  growth  due  to  the  installation  of  WWW  servers  is  extremely 
difficult  to  quantify  and  predict  accurately  without  the  proper  equipment,  resources,  and 
time  to  properly  justify  the  analysis.  Since  forecasting  and  predicting  of  both  near  and 
long-term  growth  of  network  traffic  is  difficult  to  determine,  due  to  its  various  unknown 
variables,  it  is  left  as  an  exercise  that  must  be  further  studied  by  NMIMC.  The  primary 
focus  shifted  to  the  existing  network  traffic,  and  how  to  analyze  it  and  make 
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recommendations  for  rightsizing  the  WAN  links  and  balancing  the  loads  prior  to  the 
deployment  of  the  web  servers. 

2.  Network  Data-Traffic  Review 

To  fully  understand  the  peculiar  characteristics  of  the  data  traffic  in  question,  a 
review  of  the  incoming  and  outgoing  network  traffic  was  conducted.  Several  network 
managers  and  technical  engineers  were  pooled  to  perform  an  initial  review  of  the  network 
traffic.  The  following  data  set  is  an  example  of  the  information  that  was  generated  as  a 
result  of  taking  a  snapshot  of  the  network  traffic  at  a  random  point  in  time  from  the  router 
in  the  computer  room  at  NMIMC  [Ref.  3].  This  data  set,  seen  in  Figure  2. 1,  represents 
just  one  of  the  five  links  that  are  being  anal5rzed;  it  was  our  first  look  at  the  data  that  was 
being  collected  and  monitored  by  the  router.  The  line  numbers  are  not  part  of  the  data  set, 
but  are  included  for  ease  in  fiiture  referencing  of  the  lines  of  code. 
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1 .  Fddi  0  is  up,  line  protocol  is  up 

2.  Hardware  is  cBus  Fddi,  address  is  aaOO.0400.  Ic04  (bia  0000. Ocl 8.  Ie3 8) 

3.  Description;  FDDI  Base  Backbone 

4.  Internet  address  is  131.158.100.8,  subnet  maskis  255.255.255.0 

5.  MTU  4470  bytes,  BW  100000  Kbit,  DLY  100  usee,  rely  255/255,  load  1/255 

6.  Encapsulation  SNAP,  loopback  not  set,  keepalive  not  set 

7.  ARP  ^e:  SNAP,  ARP  Timeout  4:00:00 

8.  Phy-A  state  is  active,  neighbor  is  B,  emt  signal  bits  008/20C,  status  ILS 

9.  Phy-B  state  is  active,  neighbor  is  A,  emt  signal  bits  20C/008,  status  ILS 

10.  CFM  is  thru  A,  token  rotation  5000  usee,  ring  operational  IwOd 

11.  Upstream  neighbor  0000.0cl8.le3b,  downstream  neighbor  aaOO.0400.1604 

12.  Last  input  0:00:00,  output  0:00:00,  output  hang  never 

13.  Output  queue  0/40,  0  drops;  input  queue  0/75,  0  drops 

14.  Five  minute  input  rate  66000  bits/sec,  34  packets/sec 

15.  Five  minute  output  rate  54000  bits/sec,  44  packets/sec 

16.  661479  packets  input,  169499079  bytes,  0  no  buffer 

17.  Received  5722  broadcasts,  0  runts,  0  giants 

18.  34  input  errors,  0  CRC,  34  frame,  0  overrun,  0  ignored,  0  abort 

19.  903492  packets  output,  137036303  bytes,  0  underruns 

20.  0  output  errors,  0  collisions,  0  interface  resets,  0  restarts 

21.  0  transitions,  0  traces,  0  claims,  0  beacon 


Figure  2.1.  Initial  Data  Set.  From  Re£[3]. 


B.  CAPTURING  NETWORK  DATA-TRAFFIC 
1.  Shell  Programming 

Once  the  data  traffic  under  review  was  fully  understood,  the  next  step  was  to 
figure  out  how  to  extract  the  relevant  data  so  that  it  could  be  analyzed.  The  data  that  we 
were  interested  in  is  shown  in  lines  1,  5,  14,  and  15  of  the  previous  data  set.  Since  the 
data  generated  by  the  router  snapshot  was  discrete  and  repetitive,  it  was  decided  that  shell 
programming  in  Unix  would  allow  us  a  mechanism  by  which  the  relevant  data  could  be 
captured. 
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The  “shell”  is  the  systems  command  interpreter.  It  reads  each  command  you  enter 
at  your  terminal  and  performs  the  operation  that  you  called  for.  The  shell  is  just  an 
ordinary  program  that  can  be  called  by  a  Unix  command.  [Ref.  4] 

A  mutual  decision  was  made  between  the  author  and  the  network  engineer  to 
generate  shell  scripts  that  would  take  a  sample  of  the  data  at  30  minute  intervals,  24  hours 
a  day,  seven  days  a  week,  for  at  least  two  months.  Obviously,  in  statistical  analysis,  the 
more  samples  (observations)  taken,  the  more  precise  the  calculations  and  inferences  will 
be.  Nevertheless,  the  observations  for  this  study  were  intentionally  limited  to  this  time 
sequence  in  order  to  have  sufficient  time  to  analyze  the  data  and  complete  this  study.  This 
random  sampling  should,  however,  generate  a  fairly  accurate  picture  of  the  utilization 
rates  of  NMIMC’s  five  WAN  links,  and  should  show  any  potentially  problematic  peak 
utilization  rates. 

The  scripts  were  written  in  a  Unix  Bourne  shell,  version  3.2.2,  and  run  on  an 
AT&T  3B2  server.  They  are  described  in  short  detail  in  Appendbc  B. 

2.  Revised  Data  Set 

To  clarify  once  again,  we  defined  the  data  that  we  were  interested  in.  The  scripts 
pulled  this  data  fi-om  the  original  data  set  that  was  processed  by  the  Cisco  router.  This 
revised  data  set,  which  is  shown  in  Figure  2.2,  presents  the  relevant  data  in  a  more 
meaningfiil  format.  The  five  data  links  are  now  represented  in  this  new  data  set,  which  at 
this  time  becomes  our  primary  file  of  interest.  As  indicated  earlier,  the  numbers  on  the 
extreme  left  side  are  not  actually  part  of  the  data  set.  They  are  provided  so  that  it  will  be 


easy  to  refer  to  specific  lines  of  the  data  set  in  explaining  the  meaning  of  the  data  in  the 
following  section. 


1.  . -  ■  - . —  . - — . . — 

2.  Fri  May  17  16:3 1 :00  EDT  1996 

3.  . . 

4.  Serial  1  is  up,  line  protocol  is  up 

5.  MTU  1500  bytes,  BW  56  Kbit,  DLY  20000  usee,  rely  255/255,  load  13/255 

6.  Five  minute  input  rate  2000  bits/sec,  3  packets/sec 

7.  Five  minute  output  rate  3000  bits/sec,  3  packets/sec 

8.  Serial  4  is  up,  line  protocol  is  up 

9.  MTU  1500  bytes,  BW  56  Kbit,  DLY  20000  usee,  rely  255/255,  load  150/255 

10.  Five  minute  input  rate  4000  bits/sec,  22  packets/sec 

11.  Five  minute  output  rate  33000  bits/sec,  22  packets/sec 

12.  Serial  5  is  up,  line  protocol  is  up 

13.  MTU  1500  bytes,  BW  1544  Kbit,  DLY  20000  usee,  rely  255/255,  load  1/255 

14.  Five  minute  input  rate  19000  bits/sec,  14  packets/sec 

15.  Five  minute  output  rate  5000  bits/sec,  6  packets/sec 

16.  Serial  7  is  up,  line  protocol  is  up 

17.  MTU  1500  bytes,  BW  1544  Kbit,  DLY  20000  usee,  rely  255/255,  load  1/255 

18.  Five  minute  input  rate  0  bits/sec,  1  packets/sec 

19.  Five  minute  output  rate  2000  bits/sec,  2  packets/sec 

20.  Fddi  0  is  up,  line  protocol  is  up 

21.  MTU  4470  bytes,  BW  100000  Kbit,  DLY  100  usee,  rely  255/255,  load  1/255 

22.  Five  minute  input  rate  85000  bits/sec,  75  packets/sec 

23.  Five  minute  output  rate  83000  bits/sec,  81  packets/sec 


Figure  2.2.  Revised  Data  Set.  From  Ref  [3]. 


This  revised  data  set  is  comprised  of  23  lines  of  raw  ASCII  code  that  has  been  extracted 
firom  the  original  data  set  that  was  taken  firom  the  Cisco  7000  router  [Ref  5].  This  data 
set  represents  data-trafi5c  statistics  for  the  five  WAN  links  coming  out  of  NMIMC.  The 
data  for  each  link  is  described  in  four  lines  of  code.  Since  the  code  is  identical  for  each 
link,  only  lines  4-7  will  be  explained  here. 
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On  line  4,  “Serial  1”  is  the  identifier  of  the  interface  (link).  Line  5  shows  us  MTU 
(maximum  transmission  units)  in  bj^es,  the  BW  (bandwidth)  of  the  connection,  the  DLY 
(delay)  for  the  interface,  the  RELY  (reliability)  of  the  link,  and  the  load.  Lines  6  and  7 
show  the  five  minute  input  and  output  rates,  respectively,  in  both  bits/second  and 
packets/second. 

The  sample  data  set  shown  above  depicts  the  Serial  1  interface  with  a  100% 
reliability  rate  and  a  load  of  13/255,  or  approximately  5  percent.  The  rely  and  the  load  are 
displayed  as  a  percentage  in  which  the  denominator  is  255.  The  load  counter  operates  on 
an  8-bit  value,  thus  the  significance  of  the  255  denominator  (11111111  in  binary  equals 
255).  The  load  is  computed  by  dividing  the  higher  of  the  input  or  output  rates  by  the  BW. 
For  example,  the  Serial  1  link  has  a  BW  of  56Kbit,  an  input  rate  of  2Kbits/second,  and  an 
output  rate  of  3Kbits/second.  If  you  divide  3Kbits  (the  output  rate)  by  56Kbits,  the  result 
is  5.357%,  which  is  displayed  as  a  load  of  13/255.  All  results  are  rounded  down  prior  to 
displaying  the  load  values. 

The  termination  points  of  the  five  links  out  of  NMIMC  are  shown  in  Table  2.1. 
Figure  2.3  illustrates  those  links  coming  out  of  NMIMC,  and  their  associated  termination 
locations. 
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INTERFACE  (Link) 

TERMINATION  POINT  (LOCATION) 

Serial  1 

Naval  Medical  Logistics  Command, 

Fort  Detrick,  MD 

Serial  4 

NAVNET 

Serials 

Bureau  of  Medicine  and  Surgery 
(TPC/IP  Traffic) 

Serial? 

Bureau  of  Medicine  and  Surgery 
(DEC  LAT  Traffic) 

FDDIO 

Fiber  ring  on  Bethesda  campus;  connects  Medical  Center 
and  Uniformed  Services  Universi^  of  Health  Sciences 
routers  to  the  internet 

Table  2.1.  Termination  Points  of  NMIMC’s  WAN  Links. 


Figure  2.3 .  NMIMC  WAN  Link  Sizes  and  Destinations. 
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3.  Data  Collection  and  Distribution 

The  raw  ASCII  data  that  was  captured  from  the  Cisco  router  was  immediately 
dumped  into  a  separate  ASCII  text  file,  which  was  shown  in  the  cron  entry  in  Appendix  B 
as  /usr/dsc3cjc/trovini.  Once  enough  data  was  acquired,  it  was  transferred  by  the  technical 
engineer  at  NMIMC  to  the  author  at  the  Naval  Postgraduate  School  (NPS)  by  attaching 
the  /usr/dsc3cjc/trovini  data  file  to  an  email  message. 

There  was  no  specific  cut-off  time  for  the  collection  and  transmission  of  the  data;  a 
random  stopping  point  was  chosen  by  the  network  technician  who  generated  the  script. 
Emails  were  generally  received  by  the  author  from  NMIMC  once  a  week,  typically  at  the 
end  of  the  business  week.  It  was  feared  that  if  the  script  was  allowed  to  run  and  capture 
and  dump  the  data  for  longer  than  a  week  at  a  time,  the  /user/dsc3cjc/trovini  data  file 
would  be  too  large  to  transmit  properly  without  incurring  an  occasional  “time-out”  error.  ^ 

Once  the  data  was  transmitted,  the  /user/dsc3cjc/trovini  file  was  emptied,  and  new 
data  was  captured  for  the  next  transmission.  This  iterative  process  was  continued  by  the 
NMIMC  network  technician  until  the  author  deemed  that  enough  data  was  captured  to 
perform  an  accurate  analysis  of  the  existing  traffic  loads  of  the  five  WAN  links. 


'  This  is  somewhat  of  an  insignificant  fector,  but  is  included  as  background  information  on  the  data 
collection  process.  This  scheme  may  be  of  some  value  for  those  organizations  that  are  contemplating 
performing  their  own  network  traffic  analysis,  and  need  to  collect  their  data  firom  a  remote  source. 
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C.  ANALYSIS  OF  NETWORK  DATA-TRAFFIC 


1.  Network  Traffic  FUe  Generation 

Approximately  10  weeks  worth  of  network  traffic  data  was  collected  from 
NMIMC.  Each  transmission,  or  data  dump,  that  was  received  from  NMIMC  was 
converted  from  the  email  message  format  into  a  separate  file  in  the  author’s  home 
directory  on  the  Unix  server  at  NPS.  The  email  header  and  signature  data  was  stripped 
out  of  the  message,  and  only  the  raw  traffic  data  was  saved  as  a  new  ASCII  text  file.  The 
server  platform  used  throughout  this  study  consisted  of  a  Sun  workstation  running  Sun 
O.S.  version  4.1.3. 

2.  Initial  Review  of  Captured  Network  Traffic 

The  initial  review  of  the  pure  traffic  data  consisted  of  a  quick  skimming  of  the  load 
values  as  seen  in  lines  5,  9,  13,  17,  and  21  of  the  revised  data  set.  A  portion  of  the  first 
data  file  received  was  printed  in  order  to  expedite  this  first  review;  this  hardcopy  printout 
was  used  to  highlight  specific  data.  By  using  this  printout,  it  was  easier  to  identify  the 
load  values  that  were  principally  needed  to  study.  The  individual  WAN  link  load  values 
were  reviewed  specifically  for  extremely  high  utilization  rates.  It  is  these  high  utilization 
rates  that  are  the  main  concern  of  this  study  and  the  foundation  of  this  research.  This 
basic  review  showed  some  peak  load  values,  as  well  as  those  links  that  appeared  to  have 
the  highest  utilization  rates.  The  next  step  was  to  determine  how  to  extract  that  data  from 
the  revised  data  set. 
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3.  SAS  Script  Generation 
a.  Traffic  Load  File 


Once  the  preliminary  review  was  completed,  plans  were  made  to  extract 
the  dates,  the  time  of  the  observations,  the  link  names,  and  the  load  values  from  the 
individual  data  files  so  that  a  statistical  analyses  could  be  performed  on  the  data  using  the 
Statistical  Analysis  Software  (SAS)  application.  That  script,  called  trafiSc.sas,  is  presented 
in  Appendix  C  [Ref  6],  It  computes  the  frequency  distributions  for  the  five  links,  the 
overall  minimum  and  maximum  utilization  rates  of  the  five  links,  and  generates  a 
breakdown  chart  showing  the  minimum  and  maximum  utilization  rates  by  hour.  After  the 
SAS  scripts  were  written  and  tested  on  a  small  traffic  data  file,  the  individual  traffic  data 
files  were  concatenated  into  one  file,  and  the  overall  SAS  script  was  executed.  Although 
this  SAS  script  does  not  contain  many  lines  of  code,  it  is  very  powerful  in  what  it 
accomplishes.  A  brief  discussion  of  this  SAS  script  is  presented  below  to  explain  how  the 
data  was  extracted  from  the  raw  data  traffic. 

b.  Traffic,  sas  Script  Breakdown 

The  idea  behind  the  SAS  script  is  very  easy  to  understand.  All  the  data 
found  on  the  lines  of  code  that  are  of  interest  from  the  revised  data  set  must  first  be  read 
into  the  SAS  file.  Once  that  has  been  done,  all  the  data  that  is  not  of  value  is  “dropped”, 
leaving  only  the  relevant  data  to  be  acted  upon. 

To  read  in  the  data,  the  individual  words,  or  “chunks”  of  data  on  each  line, 
which  are  separated  by  a  space,  must  first  be  labeled.  These  individual  chunks  are 
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identified  for  data  set  lines  #2,  #5,  #9,  #13,  #17,  and  #21.  For  example,  line  2  of  the  data 
set,  as  seen  below,  displays  the  date  and  time  information  of  a  particular  observation. 

#2.  Fri  May  17  16:3 1 :00  EDT  1996 

The  data  chunks  that  need  to  be  read  in  are  day,  month,  date,  and  time  of  day,  as  shown  in 
the  following  traffic,  sas  script  segment. 


#2 
day  $ 
month  $ 
date  $ 
tod$ 


Lines  #5,  #9,  #13,  #17,  and  #21  are  fairly  redundant,  and  all  contain  13  chunks  of  data. 
All  chunks  are  dropped  except  the  last  one,  which  defines  the  load  value  for  that  particular 
WAN  link.  As  an  example,  the  data  chunks  for  line  #5  are  identified  in  table  2.2,  where  si 
is  the  SAS  variable  name  assigned  to  the  data  chunk  “MTU”,  s2  is  the  SAS  variable  name 
assigned  to  data  chunk  “1500”,  and  so  forth  and  so  on. 


SAS 

Variable 

si 

s2 

s3 

s4 

s5 

s6 

s7 

s8 

s9 

slO 

sll 

sl2 

loadl 

Line  #5 

Data 

Chunk 

MTU 

1500 

bytes, 

BW 

56 

Kbit, 

DLY 

20000 

usee. 

rely 

255/255, 

load 

13/255 

Table  2.2.  SAS  Variable  Name  Definitions. 
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All  the  values  are  dropped  except  the  loadl  value,  which  is  the  actual  load  rate,  or 
utilization  rate,  for  the  seriall  link.  The  other  links  loads  are  captured  in  the  same  way.  If 
you  look  back  to  the  beginning  of  the  traffic,  sas  script,  you  will  see  where  all  the  irrelevant 
data  has  been  dropped.  The  only  data  that  are  being  captured  now  are  the  specific  dates, 
times,  and  load  values  for  the  five  WAN  links.  Once  the  relevant  data  was  filtered  out 
fi’om  the  raw  data,  the  traffic  loads  were  then  ready  to  import  into  a  spreadsheet 
application  for  plotting. 


16 


III.  DATA  ANALYSIS  AND  REPRESENTATION 


A.  VISUAL  GRAPHICS 

Once  the  exact  data  to  be  analyzed  had  been  captured,  a  method  of  illustrating  the 
data  in  an  easy  to  review  format  was  needed.  Since  S  AS  does  not  adequately  do  justice  to 
the  graphing  and  plotting  of  data  sets,  the  author  chose  Microsoft  Word  and  Microsoft 
Excel  to  plot  the  graphs  of  traffic  loads.  This  chosen  format  was  thought  to  display  the 
data  in  a  manner  that  presents  the  clearest  mental  and  visual  image  of  the  data  traffic. 


B.  A  COMPARISON  OF  MEAN  VS.  MAXIMUM  LOADS 
1.  Mean  Load  Values 

The  SAS  traffic,  sas  program  generated  a  chart  that  shows  the  mean  load  rates,  the 
standard  deviations,  and  the  minimum  and  maximum  load  rates  of  the  five  WAN  links 
under  review.  This  chart  is  presented  as  Figure  3.1.  These  rate  values  were  computed 
from  data  accumulated  over  the  period  of  23  April  -  27  June,  1996.  The  details  of  the 
computations  are  described  in  Appendix  D. 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

2359 

3.9325404 

10.6395563 

0.3921569 

98.0392157 

XLOAD4 

2359 

34.9420243 

23.3059572 

0.3921569 

100.0000000 

XLOAD5 

2359 

0.7138286 

1.1494338 

0.3921569 

28.6274510 

XLOAD7 

2359 

0.8830595 

5.1087385 

0.3921569 

98.0392157 

XLOADF 

2359 

0.3921569 

0 

0.3921569 

0.3921569 

Figure  3.1.  Load  Values.  From  Ref  [6]. 
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There  was  approximately  60  days  worth  of  data  generated  from  the  router  scripts.  Some 
of  the  data  was  lost  due  to  a  router  upgrade  on  23  May,  when  the  Cisco  AGS+  router  was 
upgraded  to  a  Cisco  7000  series  router.  This  lost  data  is  not  expected  to  make  much  of  an 
impact,  if  any,  on  the  outcome  of  this  study,  as  the  values  were  all  averaged  over  this 
observation  period.  There  were  2,359  total  observations  performed  on  each  of  the  five 
links.  The  observations  are  shown  in  Figure  3.1  under  the  variable  “N”.  The  load 
variables,  the  mean  load  values,  and  the  maximum  load  values  were  the  data  of  interest, 
and  are  duplicated  in  Table  3.1. 


Link  Name 

Variable  Name 

Line  Size 

Mean 

Maximum 

Serial  1 

XLOADl 

56  Kbps 

3.93 

98.0 

Serial4 

XLOAD4 

56  Kbps 

34.94 

100 

Serials 

XLOAD5 

T1  (1.544  Mbps) 

0.71 

28.6 

Serial? 

XLOAD7 

56  Kbps 

0.88 

98.0 

EDDIO 

XLOADF 

100  Mbps 

0.39 

0.39 

Table  3.1.  Mean  and  N 

aximum  Load  Rates. 

After  Re: 

f  [6]. 

Table  3.1  shows  the  mean  load  values  and  the  maximum  load  values  for  each  of  the  five 
WAN  links  being  reviewed.  The  data  contained  in  this  table  was  used  to  generate  the 
graphs  of  the  mean  and  maximum  load  rates,  which  will  hereafter  be  referred  to  as 
utilization  rates.  Figure  3.2  compares  the  mean  utilization  rates  of  the  five  links. 
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Mean  Traffic  Load 
(2359  observations  per  link) 


23  Apr  -  27  Jun,  1996 


Figure  3.2.  Mean  Utili2ation  Rates. 

This  graphs  clearly  shows  that  the  utilization  rates  of  all  5  links  are  well  below  what  the 
industry  considers  the  maximum  ceiling  of  80%.  [Ref  7]  If  we  compare  the  rates  against 
the  capacity  of  the  links,  we  can  begin  our  interpretation  of  whether  the  links  appear  to  be 
rightsized  or  not.  Notice  the  high  mean  rate  for  XLOAD4.  According  to  Table  3.1, 
XLOAD4  is  identified  as  a  56Kbps  line.  The  initial  indication  is  that  this  link  appears  to 
be  properly  sized;  however,  the  maximum  load  rates  should  also  be  examined  to  get  a 
better  indication  of  the  variable  traffic  utilization  rates. 

Table  3.1  also  matches  the  variable  names,  such  as  XLOADl,  to  the  link  names, 
such  as  Seriall.  Since  the  variable  names  and  link  names  are  used  interchangeably  through 
out  this  study,  this  table  will  help  to  reduce  some  of  the  confusion  surrounding  the 
naming  conventions.  The  SAS  scripts  refer  to  the  links  as  XLOADl,  XLOAD4, 
XLOAD5,  XLOAD7,  and  XLOADF,  whUe  the  Unix  scripts  and  router  data  sets  refer  to 
the  links  as  Seriall,  Serial4,  SerialS,  Serial7,  and  FDDIO. 
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2.  Maximum  Load  Values 


To  folly  appreciate  the  value  of  the  accumulated  traffic  data,  you  need  to  look 
beyond  the  mean  rates  to  the  maximum  rates.  The  peak  loads  shown  in  Figure  3.3  are  of 
great  concern,  because  at  those  high  rates  data  transmissions  not  only  tend  to  slow  down 
due  to  latency  issues,  but  data  packets  may  be  lost  once  saturation  of  the  line  is  reached  if 
the  buffers  overflow.  Generally,  TCP  will  recovers  this  loss,  which  will  be  transparent  to 
the  user.  What  the  user  may  notice  is  a  slowing  in  responsiveness.  Three  of  the  five 
WAN  links  -  Seriall,  Serial4,  and  Serial?  -  are  shown  as  exceeding  the  threshold  level  of 
80%.  These  links  should  undergo  fiirther  evaluation  to  determine  the  cause  of  the  high 
rates.  The  type  of  data  being  transmitted  and  the  time  of  day  the  transmissions  occur 
should  be  looked  at  to  uncover  the  reason  for  such  a  high  rate.  Plans  to  either  balance  the 
loads  or  rightsize  the  WAN  links  to  a  higher  bandwidth  should  be  implemented.  Methods 
of  load  balancing  and  rightsizing  of  WAN  links  will  be  addressed  in  Chapter  IV. 


Maximum  Load 


Utilization  rate 
(%) 


23  Apr -27  Jun,  1996 


Figure  3.3.  Maximum  Utilization  Rates. 


C.  GRAPHS  AND  CHARTS  OF  UTILIZATION  RATES 


1.  Houriy  Utilization  Rates 
a.  Mean  Load  Graphs 

The  SAS  script  traffic,  sas  generated  hourly  breakdown  charts,  showing  the 
mean  loads  for  each  WAN  link.  Figures  3.4  through  3.8  illustrate  the  hourly  trends  of  the 
five  links.  The  data  used  to  generate  these  graphs  are  provided  in  Appendix  D. 

Figure  3.4  shows  that  the  daily  traffic  for  the  Serial  1  link  increases  around  the  hour 
of  0600,  where  it  remains  fmrly  stable  until  it  begins  a  sharp  drop  between  the  hours  of 
1500-1700.  This  would  seem  to  indicate  that  the  traffic  load  corresponds  to  normal 
business  hours.  All  the  traffic  flowing  over  the  five  NMIMC  links  is  IP  traffic,  such  as 
Email  and  FTP  [Ref  8].  The  load  rates  seen  in  Figure  3.4  indicate  that  users  are  either 
checking  their  mail  or  transmitting  files  via  FTP  when  they  first  arrive  to  work  in  the 
morning,  again  around  lunch  time,  and  finally,  just  before  they  go  home  in  the  afternoon. 
Although  there  are  three  distinct  peaks  seen  for  XLOADl,  the  low  utilization  rates,  which 
vary  between  .58  and  9.42  percent,  give  a  good  indication  that  this  link  is  not  stressed  and 
is  properly  sized.  It  is  worth  repeating  that  the  values  represented  by  these  graphs  are 
listed  in  Appendk  D. 
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Figure  3.5  shows  that  the  traffic  pattern  for  the  Serial4  link  is  similar  to  that  of  the  Seriall 
link.  The  traffic  takes  a  significant  jump  at  0600,  remains  fairly  stable  throughout  the  day, 
and  begins  to  decline  steadily  at  1400.  The  noticeable  peaks  at  0600  and  1400  also  follow 
a  similar  pattern  noticed  for  the  Seriall  link.  The  traffic  load  for  this  link  varies  between 
18.3  and  48.9  percent.  This  is  a  significant  increase  from  the  rate  seen  for  the  Seriall  link. 
This  link  should  be  looked  at  more  closely  to  determine  if  it  is  in  fact  properly  sized.  We 
will  be  able  to  determine  a  more  accurate  indication  when  the  maximum  load  rates  are 
presented  in  the  next  section. 
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Figure  3 .6  shows  a  trend  that  is  similar  in  nature  to  the  previous  graphs.  The  traffic  begins 
to  increase  around  0700,  and  begins  to  drop  around  1400.  Two  distinct  peaks  occur  at 
0900  and  1400.  The  traffic  load  for  this  link  varies  between  .39  and  1.54  percent.  At 
these  low  utilization  rates  the  slight  increases  for  this  link  would  not  be  noticeable. 


Figure  3.7  shows  an  increase  in  utilization  beginning  at  0700,  and  tailing  off  just  after 
1200.  The  peaks  for  this  link  occur  at  1000  and  1200.  The  remaining  times  of  the  day 
show  a  very  stable  rate.  The  traffic  load  for  this  link  varies  between  .39  and  2.83  percent. 
Again,  at  this  low  utilization  rate,  the  increased  usage  at  the  peak  times  would  not  be 
noticed. 
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Figure  3 .7.  Mean  Utilization  Rate,  XLOAD7. 


The  utilization  rate  shown  in  Figure  3.8  shows  a  steady  rate  throughout  the  day.  This  may 
seem  like  an  error  at  first  glance,  however,  this  steady  rate  is  due  to  the  fact  that  the 
FDDIO  link  is  a  dual  fiber  optic  link,  running  at  100Mbps  capacity.  At  a  rate  of  0.4%,  this 
means  that  no  data  transmissions  were  above  400Kbps.  As  discussed  in  Chapter  H,  the 
loads  are  computed  by  dividing  the  higher  of  the  input  or  output  rates  by  a  divisor  of  255. 
With  the  bandwidth  set  at  100  Mbps,  and  the  input  or  output  rate  set  at  less  than  or  equal 
to  400  Kbps,  the  load  would  be  seen  as  a  steady  value  of  1/255,  or  .4%,  since  this  is  the 
smallest  value  that  can  be  represented.  The  FDDIO  link  provides  the  highest  bandwidth  of 
all  the  links  at  NMIMC.  Refer  back  to  Table  3.1  for  a  better  indication  of  the  orders  of 
magnitude  differences  in  the  capacities  of  the  links.  This  graph  appears  to  indicate  that 
there  is  a  significant  excess  of  bandwidth.  However,  the  link  is  actually  a  dual  fiber-optic 
cable,  and  the  one  time  cost  of  installing  this  fiber  is  significantly  less  than  the  monthly 
recurring  cost  of  a  56Kbps  or  higher  communication  line.  Additionally,  this  link  acts  as 
the  backbone  for  the  campus  network  in  Bethesda,  MD.  Had  this  been  a  T1  link,  then  the 
cost  of  providing  this  excess  capacity  would  surely  have  to  be  justified.  A  chart  showing 


some  of  the  costs  that  NMIMC  pays  for  their  links  is  provided  in  Chapter  IV.  Therefore, 
a  discussion  of  these  costs  will  be  deferred  until  then. 


b.  Maximum  Load  Graphs 

Just  as  in  the  case  for  the  mean  loads  discussed  in  the  previous  section,  the 
SAS  script  traffic,  sas  generated  hourly  breakdown  charts  which  show  the  maximum  loads 
for  each  of  the  five  NMIMC  WAN  links.  Figures  3.9  through  3.15  illustrate  the  hourly 
trends  of  these  links.  The  data  used  to  generate  these  graphs  are  provided  in  Appendbc  D 
along  with  the  mean  load  data.  Figure  3.9  shows  peak  loads  for  the  Seriall  link  at  0600, 
1200,  and  1500,  with  utilization  rates  of  98%,  94.5%,  and  94.5%  respectively.  Since 
these  peaks  all  exceed  the  80%  threshold,  the  Seriall  link  needs  to  be  looked  at  to  see  if 
load  balancing  can  alleviate  its  high  utilization  rate. 
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Figure  3.9.  Peak  Utilization  Rate,  XLO AD  1 . 


Figure  3.10  indicates  that  this  link  peaks  well  above  the  80%  threshold  during  almost 
every  hour  of  the  day.  In  fact,  it  falls  below  the  80%  threshold  only  once  at  2300  with  a 
utilization  rate  of  76.4%.  Since  this  link  is  NMIMC’s  only  connection  to  the  internet,  the 
statistics  indicate  that  it  should  be  rightsized  as  soon  as  possible. 
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Figure  3.10.  Peak  Utilization  Rate,  XLOAD4. 


26 


Figure  3.11  shows  a  very  pronounced  peak  at  0900.  However,  since  this  peak  load  has  a 
utilization  rate  of  just  28.6%,  it  appears  that  this  link  is  properly  sized,  and  no  further 
action  needs  to  be  taken.  However,  the  spike  in  the  busy  hour  traffic  may  be  smoothed  by 
moving  some  of  that  traffic  to  non-peak  times. 


Figure  3.11.  Peak  Utilization  Rate,  XLOAD5 . 


The  utilization  rates  seen  in  Figure  3.12  indicate  an  above  threshold  level  between  the 
hours  of  0800  and  1200.  The  utilization  rates  vary  during  this  period  from  83.9%  to 
98.0%.  Load  balancing  may  be  able  to  smooth  these  peaks,  and  should  be  viewed  as  a 
possible  corrective  action. 
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Figure  3.12.  Peak  Utilization  Rate,  XLOAD7. 


The  utilization  rates  of  the  FDDIO  link,  shown  in  Figure  3.13,  show  a  steady  rate  of  .39%. 
This  is  the  same  as  the  mean  rate  shown  in  Figure  3.8.  It  seems  that  this  fiber  link  has  a 
tremendous  amount  of  excess  capacity  to  satisfy  both  near  term  and  long  term  traffic 
increases. 


Figure  3.13.  Peak  Utilization  Rate,  XLOADF. 
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2.  Daily  Utilization  Rates 

a.  Mean  Load  Gr^hs 

Figures  3.14  through  3.20  show  that  the  only  link  that  spikes  throughout 
the  week  is  XLOAD4.  The  highest  spike  occurs  on  Wednesdays,  as  seen  in  Figure  3.16. 
The  utilization  rate  at  that  point  is  39.2.  The  mean  loads  of  the  other  links  are  extremely 
low,  an  indication  that  those  WAN  links  are  properly  sized. 
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Figure  3.14.  Average  Load  Per  Link  (Monday). 


Tuesdays'  Mean  Load 
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Figure  3.15.  Average  Load  Per  Link  (Tuesday) . 
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Wednesdays'  Mean  Load 
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Figure  3.16.  Average  Load  Per  Link  (W ednesday). 


Figure  3.17.  Average  Load  Per  Link  (Thursday). 
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Fridays'  Mean  Load 
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Figure  3.18.  Average  Load  Per  Link  Friday). 


Saturdays'  Mean  Load 
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Figure  3.19.  Average  Load  Per  Link  (Saturday). 
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Figure  3 .20.  Average  Load  Per  Link  (Sunday). 


h.  Maximum  Load  Graphs 

The  maximum  load  utilization  rates  shown  in  Figures  3.21  through  3.27 
provide  a  different  indication  than  the  mean  load  rates.  Figure  3.21  shows  three  links, 
XLOADl,  XLOAD4,  and  XLOAD7  as  having  utilization  rates  that  exceed  the  80% 
threshold.  Their  load  rates  are  83.9%,  98%,  and  98%  respectively. 
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Figure  3 .2 1 .  Maximum  Load  Per  Link  (Monday). 
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Figure  3.22  is  similar  to  the  previous  graph,  except  XLOAD7  drops  from  98%  to  56.8%. 
The  utilization  rates  for  XLOADl  and  XLOAD4  remain  extremely  high  at  92.5%  and 
98%  respectively. 


Tuesdays'  Maximum  Load 
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Figure  3.22.  Maximum  Load  Per  Link  (Tuesday). 


The  utilization  rates  in  Figures  3.23  through  3.25  are  nearly  identical,  with  XLOADl  and 
XLOAD4  again  nearly  maxing  out  with  utilization  rates  that  fluctuate  between  94.5%  and 
100%. 
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Wednesdays'  Maximum  Load 
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Figure  3.23.  Maximum  Load  Per  Link  (W ednesday). 


Thursdays'  Maximum  Load 
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Figure  3 .24.  Maximum  Load  Per  Link  (Thursday). 
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Fridays'  Maximum  Load 
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Figure  3 .25 .  Maximum  Load  Per  Link  (Friday). 


Figures  3.26  and  3.27  show  the  XLOADl  rates  dropping  below  20%,  while  XLOAD4 
remains  peaked  at  92.5%  and  94.5%  respectively. 


Saturdays'  Maximum  Load 


XLOADl  XL0AD4  XL0AD5  XLOAD7  XLOADF 


NMlMC's  WAN  Links 


Figure  3 .26.  Maximum  Load  Per  Link  (Saturday). 
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Sundays'  Maximum  Load 
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Figure  221.  Maximum  Load  Per  Link  (Sunday). 

It  is  interesting  to  note  that  XLOAD4  was  the  only  link  that  nearly  attained  the  maximum 
value  with  spikes  up  to  100%.  These  graphs  indicate  the  need  to  thoroughly  review  links 
XLOADl,  XLOAD4,  and  XLOAD7.  Plans  to  either  balance  the  loads  on  those  links  or 
increase  the  size  of  the  links  need  to  be  implemented  immediately.  These  methodologies 
will  be  discussed  briefly  in  Chapter  IV. 

D.  BENEFITS  OF  TREND  ANALYSIS 
1.  Needs  Assessment 

The  primary  signijScance  of  analyzing  the  utilization  rates  is  to  help  you  assess  your 
need  to  adjust  your  bandwidth  requirements.  The  average  rates,  as  illustrated  in  Figure 
3.2,  do  not  provide  an  accurate  measurement  of  the  usage  of  the  various  WAN  links.  You 
must  also  identify  the  peak  loads,  as  identified  in  Figure  3.3,  and  let  the  data  tell  you  if  you 
are  properly  positioned  to  provide  the  support  necessary  to  handle  your  organizations 
traffic  loads.  If  not,  corrective  actions  must  be  taken  to  rightsize  those  links. 
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2.  Down  Time  and  Scheduled  Maintenance 


An  added  benefit  of  perfonning  an  analysis  of  the  hourly  and  daily  utilization  rates 
is  the  identification  of  low  utilization  periods.  These  lower  usage  periods  are  of  significant 
value  because  they  pinpoint  times  that  can  be  used  to  the  organization’s  advantage.  From 
an  IT  manager’s  and  system  administrator’s  point  of  view,  these  sags  in  utilization  rates 
are  an  ideal  time  for  scheduling  down-time  required  to  support  periodic  maintenance  of 
systems,  including  mainfi-ames,  routers,  and  other  peripheral  equipment. 

3.  ReliabUity  and  AvaUability 

The  data  sets  that  were  provided  by  the  router,  shown  in  Chapter  n,  show  the 
reliability  of  the  network  links,  as  well  as  the  traffic  loads.  Analyzing  the  statistics  fi-om 
the  network  router  can  help  you  identify  any  degradation  in  the  reliability  of  your  network 
links.  Less  than  perfect  reliability  rates  impact  the  av^ability  of  your  links,  which  in  turn 
causes  delays  in  data  transmissions,  and  significantly  decreases  the  support  that  you  are 
able  to  offer  your  customers.  Chapter  VI  discusses  the  meaning  and  the  importance  of 
operational  availability,  so  details  will  be  deferred  until  then. 
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IV.  LOAD  BALANCING  AND  RIGHTSIZING  OF  WAN  LINKS 


A.  PROBLEM  ISOLATION  AND  RESOLUTION 

This  chapter  focuses  on  identifying,  isolating,  and  solving  problems  that  impede 
throughput  performance  in  networks.  In  general,  performance  slowdowns  are  considered 
lower-priority  problems  than  reachability  issues.  However,  poorly  performing 
internetworks  can  degrade  organizational  productivity  and  often  can  effectively  halt 
operations  of  network  applications  if  communications  degenerates  enough.  Performance 
problems  can  reveal  themselves  in  many  ways.  Slow  host  response,  dropped  cormections, 
latency,  and  high  error  counts  all  suggest  that  network  performance  is  not  optimal. 
Unfortunately,  the  actual  sources  of  performance  problems  are  often  difficult  to  detect. 
[Ref  9] 

This  chapter  introduces  an  example  problem-solving  scenario  that  illustrates  the 
process  of  problem  isolation  and  resolution.  Since  certain  common  themes  are  present  in 
most  coimectivity  problems,  this  chapter  is  provided  in  an  effort  to  illustrate  the  use  of 
troubleshooting  tools  and  techniques  to  identify  those  common  themes.  [Ref  9]. 


B.  METHODS  OF  LOAD  BALANCING 
1.  Redundant  Links 

Remote  bridges  and  routers  often  utilize  load  balancing,  which  is  a  uniform 
distribution  of  data  over  parallel  links.  These  links  can  be  similar  or  dissimilar.  One  link 
may  have  a  transmission  rate  of  56  Kbps,  while  the  other  may  be  transmitting  at  128  Kbps. 
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Generally,  the  network  administrator  will  define  the  two  links  as  a  single  logical  link.  The 
benefit  of  redundant  links  is  that  in  the  event  the  primary  link  goes  down,  the  secondary 
link  becomes  active  and  allows  the  continued  transmission  of  data  packets  throughout  the 
network.  [Ref  10] 

2.  Improving  Poor  Performance  Over  A  TCP/IP  WAN 

0.  Environment  Description 

This  section  is  concerned  with  performance  in  a  TCP/IP  internetwork 
featuring  parallel  serial  links  that  join  two  geographically  separated  locations  via  IP 
routers^.  This  analysis  focuses  on  isolating  problems  and  then  considering  options  for 
relieving  congestion. 

Figure  4. 1  shows  the  layout  of  the  routers  of  the  internetwork  discussed  in 
this  example.  The  assumption  is  that  the  traffic  to  the  main  campus  consists  of  FTP, 
Telnet,  and  E-mail^.  For  discussion  purposes,  we  shall  say  that  the  users  at  Remote  Site-A 
are  complaining  about  poor  host  response  and  slow  performance  when  connecting  to 
hosts  at  the  main  Campus.  In  addition,  during  certain  times  of  the  day,  large  files  are 
being  transferred  over  the  serial  network.  At  these  times,  the  traffic  becomes  especially 
slow,  but  does  not  stop. 

The  first  thing  to  do  is  to  identify  all  likely  possible  causes.  The  second 
step  is  to  eliminate  each  one.  The  following  problems  are  the  most  likely  candidates  for 
interconnection  failure: 

’  Any  IP  router  will  do;  NMIMC  uses  Cisco  routers . 

^  Another  assumption  is  that  Unix  workstations  are  being  used  at  the  remote  site. 
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•  Overloaded  server 

•  Bad  Ethernet  or  serial  line 

•  Congestion: 

1.  at  routers 

2.  at  servers 

3.  on  serial  lines 

4.  due  to  inappropriate  WAN  technology 

In  an  effort  to  keep  this  chapter  concise,  only  a  brief  review  of  the 

highlights  of  these  problem  isolation  processes  is  given.  More  detailed  information 
regarding  the  process  of  problem  isolation  can  be  found  by  visiting  various  vendors’  home 
pages^. 


MAIN  CAMPUS  REMOTE  SHE-A 


Figure  4.1.  Dual  56  Kbps  Serial  Link  TCP/IP  Internet.  After  Ref  [10]. 


^  Cisco’s  home  page  can  be  found  at  URL  http://www.cisco.com.  The  user  can  sign  on  as  a  guest,  then  go 
to  the  first  page  after  the  home  page  and  select  the  hypertext  link  to  Univer  CD-ROM.  An  extensive  index 
of  Performance  Problem  Scenarios  and  associated  problem  isolation  processes  can  be  found  there. 
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b.  Problem  Isolation 


The  first  thing  to  do  is  to  determine  the  condition  of  the  serial  line.  A 
preliminary  check  can  be  performed  by  using  the  ‘^how  interfaces”  command.  The  user 
should  also  check  to  see  if  input  errors,  output  drops,  or  interface  resets  are  high,  as 
indicated  in  Figure  4.2,  lines  8,  13,  and  15.  These  conditions  would  indicate  that  the 
Serial-O  line  is  overutilized.  If  the  router  reports  that  ‘Serial-0  is  up,  line  protocol  is  up” 
you  can  assume  that  the  serial  line  is  functional,  as  well  as  the  central  office  switches, 
intervening  CSU/DSU,  etc.  The  user  should  now  perform  a  ‘t)ing”  test  to  isolate  the 
traffic  bottleneck.  This  test  should  identify  excessive  packet  drops,  server  failures  ,  and 
time-out  errors.  Be  sure  to  ping  various  nodes  in  the  path,  as  seen  in  Figure  4.1, 
beginning  with  the  router  closest  to  the  remote  hosts,  looking  for  the  point  at  which  drops 
start  to  occur.  If  those  tests  indicate  no  problems,  ping  between  the  routers.  If  these  tests 
all  pass,  and  you  determine  that  the  problem  is  indeed  one  of  congestion  due  to  bandwidth 
overutilization,  you  must  then  decide  whether  it  is  more  effective  to  add  bandwidth  or  to 
make  an  adjustment  in  the  router  configuration.  [Ref.  9] 

If  system  administrators  receive  load  values  of  about  50  percent,  high  input 
errors  or  output  drops,  they  may  consider  implementing  priority  queuing  to  force  Telnet 
to  be  given  a  higher  precedence  over  other  packet  types.  This  helps  ensure  reasonable 
connection  service  to  users,  even  during  periods  when  file  transfers  are  taking  place.  It  is 
important  to  note  that  one  reason  why  Telnet  traffic  can  be  bumped  fi'om  the  buffer 
queues  is  the  tendency  of  the  larger  FTP  packet  types  to  collect  in  the  router’s  buffers. 
When  FTP  traffic  is  high,  the  smaller  Telnet  packets  are  squeezed  out  of  the  input  or 


output  queues,  resulting  in  retransmissions,  session  time-outs,  and  generally  slower 
connection  performance.  By  using  priority  queuing,  marginal  cases  can  be  relieved. 

[Ref  9] 


1.  Serial  0  is  up,  line  protocol  is  up 

2.  Hardware  is  MCI  Serial 

3.  Internet  address  is  131.158.100.8,  subnet  mask  is  255.255.255.0 

4.  MTU  1500  bytes,  BW  56  Kbit,  DLY  20000  usee,  rely  255/255,  load  1/255 

5.  Encapsulation  HDLC,  loopback  not  set,  keepalive  set 

6.  Last  input  0:00:00,  output  0:00:00,  output  hang  never 
7  Last  clearing  of  “show  interface”  counters  never 

8.  Output  queue  0/40, 78253  drops;  input  queue  0/75, 0  drops 

9.  Five  minute  input  rate  44000  bits/sec,  58  packets/sec 

10.  Five  minute  output  rate  41000  bits/sec,  49  packets/sec 

11.  4481625  packets  input,  681913058  bytes,  19  no  buffer 

12.  Received  117015  broadcasts,  0  runts,  0  giants 

13.  1145  input  errors,  160  CRC,  581  frame,  0  overrun,  0  ignored,  0  abort 

14.  5003523  packets  ouq>ut,  2819930198  bytes,  0  underruns 

15.  0  ouq>ut  enors,  0  collisions,  863 1  interface  resets, 

16.  15  carrier  transitions 


Figure  4.2.  Display  Output  of  Show  Interfaces  Command.  From  Ref.  [9]. 


If  you  are  seeing  load  values  close  to  90  percent,  as  well  as  input  errors 
and  output  drops,  priority  queuing  is  not  likely  to  do  any  good.  With  consistently  high 
congestion,  you  are  better  off  adding  new  serial  links,  or  increasing  the  size  of  your 
existing  links.  [Ref  9] 

In  summary,  the  following  problem  resolution  topics  were  discussed  as 
being  potential  resolutions  to  performance  problems  in  TCP/BP  internetworks: 
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•  Isolating  problem  nodes  and  eliminating  potential  problems  using  extended 
ping  tests. 

•  Determining  when  to  tweak  your  configuration  with  priority  queuing  and  when 
to  add  bandwidth 

•  Specifying  priory  queuing  to  force  the  router  to  give  a  specific  TCP/IP  socket 
a  higher  priority  than  other  protocols 


C.  RIGHTSIZING  THE  WAN  LINKS 

1.  Data-Driven  Decision  Management 

Chapter  m  discussed  the  traffic  flows  of  the  WAN  links  under  review.  By 
continually  analyzing  their  organizations  WAN  links,  administrators  will  be  in  better 
position  to  rightsize  their  links  before  bottlenecks  cause  excessive  delays  and  causes  then- 
system  to  crash.  Organizations  should  promote  a  data-driven  decision  management 
methodology,  which  stresses  the  use  of  historical  data  to  assist  managers  in  making 
strategic  decisions  regarding  the  networking  needs  of  their  customers/users. 

The  graphs  illustrated  in  chapter  HI  show  the  need  to  increase  the  size  of  several 
links.  Table  4. 1  shows  the  increase  in  bandwidth,  and  the  associated  recurring  and  non¬ 
recurring  costs  (NRC),  proposed  by  NMIMC  for  several  CONUS  commands  currently 
linked  to  the  DISN  NIPRNET.  Of  these,  the  increase  in  bandwidth  associated  with  Naval 
Hospitals  Great  Lakes,  Groton,  Bremerton,  and  Pensacola  are  important.  These  four  sites 
are  scheduled  to  receive  WWW  servers  in  the  near  future.  Are  the  proposed  increases  in 
bandwidth  sufficient  to  satisfy  the  future  load  requirement  placed  on  those  communication 
lines  by  the  increased  traffic  from  WWW  activity?  It  appears  that  they  are,  but  the 
unknown  variable  in  this  assessment  is  the  future  traffic  growth. 
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The  cnix  of  this  research  has  focused  on  analyzing  the  existing  traffic  loads  of  the 
WAN  links  at  NMIMC.  By  analyzing  today’s  traffic  loads,  we  can  recommend 
appropriate  sized  lines  to  satisfy  our  current  requirements.  The  missing  link,  however,  is 
the  future  traffic  growth  placed  on  those  links  after  the  WWW  servers  are  installed.  By 
analyzing  today’s  needs  and  projecting  future  requirements,  activities  can  then  make 
recommendations  for  rightsizing  their  links  accordingly. 


# 

Site  Name 

Cuirent  BW 

Current  Cost 

NewBW 

New  Cost 

Increase 

NRC  Charge 

1 

NAVHOSP 

Bremerton 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

2 

NAVHOSP  Camp 

Pendleton 

56K 

$1,875.00 

$8,635.00 

$6,760.00 

$5,000.00 

3 

NMC 

San  Diego 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

1 

NAVHOSP 

Jacksonville 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

5 

NAVHOSP  Camp 

Lejeune 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

6 

NMC  Portsmouth 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

1 

NAVHOSP 

Pax  River 

0 

256K 

$4,024.00 

$4,024.00 

$2,500.00 

8 

NNMC  Bethesda 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

9 

NAVHOSP  Groton 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

10 

NAVHOSP  Great 

Lakes 

56K 

$1,875.00 

T-1 

$8,635.00 

$6,760.00 

$5,000.00 

Table  4.1.  DISNNl 

DPKNET  Bandwidth  Increases  and ; 

Monthly  Costs.  From  Ref  [11]. 
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2.  Cost  vs.  Performance  Trade-Off 


Before  deciding  to  change  the  size  of  their  communications  lines,  information 
managers  need  to  evaluate  their  current  trafiSc  flows  and  let  that  data  drive  their  decision 
as  to  what  size  link  is  the  correct  size  for  the  organization.  Additionally,  managers  need  to 
check  their  budgets  to  see  if  they  can  afford  the  new  link.  The  bottom  line  is  that  if  they 
don’t  install  the  correct  sized  links,  the  organization  will  not  be  operating  as  effectively  or 
efficiently  as  it  could  be.  Lost  data  due  to  incorrectly  sized  communication  lines  is  not  an 
economically  acceptable  practice.  Organizations  will  lose  their  competitive  advantage  if 
their  data  does  not  flow  in  a  timely  fashion. 

Likewise,  it  is  not  acceptable  for  an  organization  to  waste  funds  on  installing  a  link 
that  has  excess  capacity  that  will  not  be  used  for  a  year  or  two.  To  assist  in  making  the 
right  decision,  a  cost  benefit  analysis  should  be  performed.  This  analysis  should  balance 
the  funds  available  for  communication  lines  against  the  right  sized  line  to  accomplish  the 
mission.  If  you  have  the  funds  in  your  budget,  it  would  be  better  to  get  a  little  extra 
capacity  to  ensure  that  the  data  will  flow  when  the  traffic  loads  spike.  In  reality,  there  is 
no  such  thing  as  ‘too  much  capacity”.  If  you  can  afford  it,  put  in  a  bigger  pipe,  but  be 
careful  not  to  install  a  big  pipe  just  for  sake  of  having  one. 

Table  4.2  shows  the  costs  associated  with  various  sized  lines  as  provided  by  DISN, 
including  the  monthly  recurring  fees  as  well  as  the  one-time  installation  costs.  You  will 
notice  that  the  costs  almost  double  from  one  size  to  the  next.  From  this  table  it  should  be 
quite  clear  that  the  importance  of  rightsizing  your  organizations  WAN  links  can  result  in  a 
significant  cost  avoidance  if  done  properly. 
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Rate 

Monthly  Recurring 

Costs 

CONUS 

Monthly  Recurring 

Costs 

EUROPE 

Monthly  Recurring 

Costs 

PACMC 

Non  Recurring 

Costs 

Ethernet 

$3,836.00 

$5,385.00 

$7,308.00 

$2,500.00 

9.6  Kb 

649.00 

884.00 

1,103.00 

2,500.00 

19.2  Kb 

1,066.00 

1,386.00 

1,813.00 

2,500.00 

56/64  Kb 

1,875.00 

2,437.00 

3,187.00 

2,500.00 

128  Kb 

2,747.00 

4,120.00 

5,768.00 

2,500.00 

256  Kb 

4,024.00 

6,035.00 

8,450.00 

2,500.00 

512  Kb 

5,895.00 

8,842.00 

12,379.00 

2,500.00 

1.544  Mb  (T-1) 

8,635.00 

N/A 

N/A 

5,000.00 

2.048  Mb 

(OCONUS) 

N/A 

12,954.00 

12,954.00 

5,000.00 

1 

fable  4.2.  1996  Cost  for  DISN  Service.  From  Ref  [11] 
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V.  HEALTH  CARE  TRENDS  AND  THE  NECESSITY  FOR 
GREATER  BANDWIDTH 


A.  TRENDS  IN  HEALTH  CARE  COMPUTING 

1.  Information  Systems  Priorities 

The  most  important  Information  Systems  (IS)  Priorities  for  health  care 
organizations  are  upgrading  their  IT  infrastructures  and  integrating  systems  in  a 
multivendor  environment.  Re-engineering  to  a  patient-centered  computing  environment  is 
also  receiving  priority  attention  from  health  care  organizations.  Figure  5.1  shows  the 
breakdown  of  the  IS  priorities.  The  ratio  between  network  and  end  systems  was  not 
available.  The  survey  base  was  more  heavily  tilted  toward  the  civilian  sector,  rather  than 
the  military,  but  applies  to  both  nonetheless.  [Ref  12] 


Miscellaneous 

18% 


Re¬ 

engineering 

23% 


Upgrading  iT 
Infrastructure 
32% 


Integrating 
Systems 
27% 

Figure  5.1.  Greatest  IS  Priorities.  From  Ref  [12]. 


Reflecting  the  larger  trend  in  health  care  delivery,  computer  technology  is 
distancing  itself  beyond  the  boundaries  of  the  traditional  hospitals  environment.  The  two 
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largest  departmental  automation  priorities  for  the  upcoming  year  are  physicians’  offices 
and  outpatient  clinics,  far  outpacing  traditional  inpatient  settings  such  as  critical  care,  OR, 
and  Med/Surgery.  [Ref  12] 

In  the  outpatient  setting,  shown  in  Figure  5.2,  the  greatest  advantage  of  IT  is 
access  to  current  patient  information  across  the  enterprise,  essentially  taking  the  care  to 
the  patients,  rather  than  vice  versa.  Other  advantages  cited  are:  automating  workflow; 
better  financial  management  of  offices;  and  better  management  of  non-clinical  patient 
tasks. 


Better  of 
NbKJTrical 
MsceSaneous  F^tiert  Tasks 
7%  13% 


45%  AUorrating 


WsrkflGW 

19% 


Figure  5.2.  The  Greatest  Advantage  of  IT  in  an  Outpatient 


Setting.  From  Ref  [12]. 


2.  The  Internet  and  the  World  Wide  Web  in  Health  Care 

The  revolution  in  cyberspace  has  reached  health  care.  In  a  recent  survey  of  trends 
in  health  care  computing,  more  than  1,200  respondents  provided  their  answers  to 
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questions  concerning  the  use  of  the  Internet,  the  use  of  telemedicine,  WWW  home  pages, 
and  future  uses  of  the  Internet. 

Figure  5.3  shows  the  telemedicine  commitment  or  those  organizations  surveyed. 
The  chart  shows  that  76  percent  of  the  organizations  are  either  currently  using  this 
technology,  or  are  actively  investigating  the  use  of  it. 


No,  but 

investigating  it 
actively 
36% 


Yes, 

somew  hat 
involved 
31% 


Not  involved 
19% 


Other 

4% 


Yes,  heavily 
Involved 
10% 


Figure  5.3.  Telemedicine  Commitment.  From  Ref  [12]. 


Those  organizations  that  stated  that  they  were  either  heavily  involved  or  somewhat 
involved  with  telemedicine  were  asked,  ‘How  many  network-based  consultations  has  your 
organization  conducted  in  the  past  year"?  Those  results  are  illustrated  in  Figure  5.4.  It  is 
interesting  to  note  that  52  percent  of  those  organizations  conducted  200  or  more 
telemedicine  consultations  per  year. 
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Figure  5.4.  Network-based  Consultations 
Conducted  in  Past  Year.  From  Ref.  [12]. 


Continuing  with  the  telemedicine  technology,  the  using  organizations  were  asked 
to  select  all  the  applications  for  which  their  organization  was  currently  using  or 
considering  using  from  a  preselected  list.  Those  results  are  illustrated  in  Figure  5.5. 

Figure  5.6  shows  the  results  of  the  question,  ‘How  is  your  organization  currently 
using  the  Internet’?  The  numbers  add  up  to  more  than  100  percent,  because  they  were 
asked  to  choose  all  that  apply.  Only  19  percent  of  those  surveyed  said  that  their 
organization  was  not  currently  using  the  internet.  This  indicates  the  growing  number  of 
organizations  who  are  getting  connected  to  the  internet  in  order  to  maint^  their 
competitive  advantage  in  their  profession. 
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Figure  5.5.  Telemedicine  Applications.  From  Ref.  [12]. 
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Figure  5.6.  Use  of  the  Internet.  From  Ref.  [12]. 
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Figure  5.7  shows  the  breakdown  of  those  health  care  organizations  that  have  a 
WWW  home  page,  and  the  length  of  time  they  have  been  operational.  The  chart  shows 
that  73  percent  of  those  activities  either  have  an  active  web  page  or  are  in  the  process  of 
developing  one.  Again,  this  is  a  clear  indication  of  the  direction  the  health  care  industry  is 
heading  with  regard  to  computer  and  information  technology. 


No,  but  we 
are  developing 
a  site. 

36% 


Yes,  for  less 
than  a  year. 
24% 


No,  no  current 
plans  to 
develop  a  site. 


Yes,  for  nrore 
than  one  year. 
13% 


27% 


Figure  5.7.  Percentage  of  Active  WWW  Home  Pages. 
From  Ref  [12]. 


Figure  5.8  illustrates  the  top  futuristic  health  care  technology  that  the  participating 
organizations  think  will  probably  come  into  common  use  within  the  next  five  years.  The 
use  of  the  internet  is  clearly  evident  by  the  responses  to  this  question,  as  50  percent  said 
either  telemedicine  from  the  home  or  medical  records  access  via  the  internet  would  be 
introduced. 
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27% 

via  the  Internet 
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Automated 
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Drug 

Disbursement 

14% 


Figure  5.8.  Future  Health  Care  Technology. 
From  Ref.  [12]. 


B.  TARGET  SYSTEM 

It  is  clear  to  see  that  the  future  of  health  care  is  going  to  be  highly  dependent  on 
advanced  technology.  Hospitals,  HMOs,  and  providers  must  embrace  leading  edge 
technology  and  apply  it  to  their  migration  systems  in  order  to  be  in  position  to  provide  the 
best  health  care  to  patients.  One  of  the  first  steps  health  care  facilities  should  take  to 
ensure  that  their  enterprise  is  functioning  as  effectively  and  efficiently  as  possible  is  to 
ensure  that  the  bandwidth  needed  to  transmit  information  -  whether  it  is  email, 
transmission  of  administrative  or  patient  information  via  FTP,  televideo  conferencing,  or 
telemedicine  -  is  properly  sized  and  available.  By  adopting  a  policy  that  requires  your 
network  administrator  to  perform  a  daily  analysis  of  your  network  data  traffic,  you  will  be 
in  a  great  position  to  ensure  that  your  WAN  links  are  rightsized  and  ready  to  support  your 
users. 
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C.  MILITARY  ENVIRONMENT 


The  results  of  the  survey  that  generated  the  figures  on  the  preceding  pages  are 
believed  to  be  based  on  a  predominantly  civilian  based  population.  However,  the  results 
can  easily  be  mapped  into  the  military  community.  The  author  believes  that  most  of  these 
trends  are  amplified  in  the  military  environment  for  the  following  reasons: 

•  larger  medical  trainee  population 

•  larger  percentage  of  remote  patients 

•  higher  percentage  of  independent  duty  corpsmen 

•  combat  t3^e  injuries  (higher  puncture/shrapnel  wounds  and  shock)  vice  civilian 
mix  of  casualties  and  ailments 

The  assumption  is  that  the  trends  displayed  for  the  civilian  sector  are  also  appropriate  for 
the  miUtary. 
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VI.  AVAILABILITY  OF  NETWORK  LINKS 

A.  AVAILABILITY  HEURISTIC 

The  trends  in  health  care,  shown  in  Chapter  V,  imply  an  ever  increasing  need  for 
higher  bandwidths  and  availability.  High  network  availability  can  be  defined  as  the 
likelihood  that  any  given  user  can  gain  access  to  and  successfully  use  the  system  at  a  given 
moment.  It  includes  survivability  and  restorability  in  both  peacetime  and  wartime 
emergencies,  reliability  of  individual  elements,  physical  redundancy,  and  a  system  design 
responsive  to  changes  in  network  design  and  connectivity.  [Ref  13] 

How  critical  and  timely  are  your  data  transmissions?  Are  you  dealing  with  time 
sensitive,  life  threatening  issues  that  must  be  dealt  with  immediately?  Can  you  afford  to 
experience  down  time,  and  if  so,  how  much?  These  are  a  few  of  the  questions  that  you 
must  answer  to  determine  the  level  of  availability  that  you  are  seeking  for  your 
organization. 

This  chapter  discusses  the  importance  of  Operational  Availability,  which  in  the 
engineering  field  is  denoted  as  Ao  [Ref  14],  Ao  is  usually  expressed  as  a  percentage,  and 
is  defined  as  up  time  (total  time  minus  down  time)  divided  by  total  time. 

The  primary  means  for  achieving  high  availabihty  consists  of:  [Ref  15] 

•  design  -  installing  or  making  use  of  redundant  equipment  and  communications 
means  so  that  backup  alternatives  are  available  when  equipment  fails 

•  logistics  -  planning  for  component  failures  with  management,  backups,  spare 
parts,  and  maintenance  training 

•  management  -  rapidly  identifying  and  correcting  malfunctioning  equipment  and 
bottlenecks 
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B.  AVAILABILITY  ENGINEERING  MODEL 

1.  Single-Threaded  Model 

Figure  6.1  presents  a  model  of  a  single-threaded  network.  The  availability  figures 
for  these  components  may  be  obtained  firom  the  vendors  or  suppliers,  or  may  be  estimated 
fi-om  experience.  The  Ao  of  the  individual  components  for  our  model  are  hypothetically 
set  as  follows:  [Ref  14] 

•  WAN  (line)  Ao  =  99.7% 

•  router  Ao  =  99.9% 

•  LAN  and  end  system  Ao  =  99% 


Figure  6.1.  Single-Threaded  System. 
After  Ref  [14]. 


In  the  field  of  applied  statistics  and  probability,  it  is  standard  procedure  to  quantify 
the  likelihood,  or  chance,  that  an  event  will  occur.  The  likelihood  of  a  particular  outcome 


is  quantified  by  assigning  a  number  fi'om  the  interval  [0,1]  to  the  outcome  (or  a  percentage 
fi-om  0  to  100%).  The  higher  the  number,  the  greater  the  chance  of  occurrence  of  that 
event.  A  zero  indicates  that  an  outcome  will  never  occur,  while  a  1  indicates  that  an 
outcome  will  occur  with  certainty.  [Ref  16] 

Since  the  three  components  in  our  model  are  wired  in  series,  the  Ao  of  the  system 
can  be  expressed  as  the  product  of  the  three  component  values: 

Ao  =  0.997x0.999x0.99 
=  0.986 

To  put  our  model  into  perspective,  the  total  time  per  month  should  first  be  computed,  as 
seen  in  Figure  6.2.  When  you  apply  the  above  Ao  value  and  monthly  total  time  value  to 
the  Ao  formula,  you  arrive  at  a  monthly  down  time  value  of  605  minutes.  This  equates  to 
approximately  10  hours  of  down  time  per  month. 

Attempts  to  increase  the  Ao  value  of  the  components  is  limited  to  technology,  i.e., 
solid  state  devices.  Therefore,  in  order  to  obtain  a  greater  availability,  we  must  emulate 
our  components  and  solve  our  Ao  problems  through  redundancy.  [Ref  14] 
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60  min/hr 
X  24  hr/dav 
1,440  min/day 
X  30  davs/month 
43,200  min/month 

if  Ao  =  up  time/total  time, 

where  Ao  =  0.986 

and 

total  time  =  43,200  min/mo, 
then 

0.986  =  43,200  -  down  time/43,200 
down  time  =  605  min/mo _ 

Figure  6.2.  Calculation  of  Down  Time. 


2.  Redundancy  Criteria 

a.  Three  Criteria  of  High  Availability 

To  assist  you  in  maintaining  the  highest  network  availability  as  possible,  the 
three  principles  of  high  availability  engineering  are  hereby  provided:  [Ref  14] 

•  eliminate  single  points  of  failure 

•  provide  reliable  crossover  (from  primary  to  backup) 

•  promptly  detect  &  correct  failures  upon  occurrence 


b.  Eliminating  Common  Cause  Failures 

A  common  cause  failure  is  defined  as  a  failure  of  one  component  that 
causes  another  component,  typically  the  backup,  to  fail.  By  implementing  engineering 
independence,  we  can  eliminate  common  cause  fdlures.  An  example  would  be  placing 
individual  computers  within  an  organization  on  separate  uninterruptable  power  supplies 
(UPS)  so  that  the  failure  of  one  UPS  will  not  cause  aU  the  computers  in  the  office  to  go 
down.  Another  example  is  to  bring  in  telephone  trunks  (lines)  into  a  command  center 
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from  more  than  one  central  ofiBce  (CO).  By  using  two  different  routes,  you  will  avoid  the 
vulnerability  associated  with  a  CO  shut  down,  which  could  be  caused  by  a  jBre,  or  by  the 
rupturing  of  buried  cables.  [Ref.  15] 

c.  Reliable  Crossover 

The  changeover  of  a  system  from  primary  to  backup  mechanisms  must  be 
reliable.  It  simply  is  not  acceptable  to  have  the  backup  systems  unavailable  when  they  are 
needed.  This  criterion  of  high  availability  coincides  with  networking  standards  that  tend 
to  use  all  the  connectivity,  both  primary  and  backup,  all  the  time.  In  addition  to  the 
efficiency  gains  (equipment  and  communications  capacity  not  being  idle),  the  reliability  of 
the  changeover  mechanism  is  quite  high  as  it  is  exercised  continually  in  the  course  of 
normal  business.  Fortunately,  this  problem  is  handled  quite  nicely  by  the  TCP/IP  protocol 
stack  for  internetworks  and  by  FDDI  ring-wrap  in  LANs.  [Ref  15] 

d.  Detection  of  Failures  Upon  Occurrence 

Since  high  availability  systems  use  backups,  it  is  necessary  to  detect  failures 
in  primary  equipment  so  that  operations  can  be  switched  over  to  backups  so  that  the 
primary  equipment  can  be  repaired  before  the  backup  equipment  fails.  Although  the 
ability  to  rectify  communications  problems  in  a  timely  and  efficient  manner  is  important,  it 
is  more  important  to  recognize  potential  problems  before  they  occur  and  cause 
communication  outages,  excessive  response  times,  or  other  types  of  impairments.  This  is 
the  function  of  the  network  management  process,  which  is  defined  as:  [Ref  17] 
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...the  process  of  using  hardware  and  software  by  trained  personnel  to 
monitor  the  status  of  network  components  and  line  facilities,  question  end- 
users  and  carrier  personnel,  and  implement  or  recommend  actions  to 
alleviate  outages  and/or  improve  communications  performance  as  well  as 
conduct  administrative  tasks  associated  with  the  operation  of  the  network. 

By  embracing  the  high  availability  principles,  you  can  ensure  that  your  organization  is  well 
positioned  to  deal  with  any  potential  network  or  communication  problems  that  may  occur. 
By  maintaining  a  proactive,  rather  than  a  reactive  posture,  you  will  be  in  position  to  take 
action  to  conquer  problems  before  they  occur,  or  before  they  get  out  of  control. 

3.  Dual-Threaded  Model 

Dual-threaded  systems  are  the  best  way  to  eliminate  single  points  of  failure.  As 
mentioned  earlier,  connectivity  into  the  facility  should  be  brought  in  via  two  separate 
central  offices  and  through  two  different  cable  trenches  or  conduits.  The  routers  should 
be  cross-connected,  protected  with  separate  UPS  units,  and  installed  in  different  wiring 
closets,  preferably  in  different  buildings.  Additionally,  if  the  LANs  are  compatible,  they 
should  also  be  cross-coimected  by  installing  a  bridge.  The  ideal  situation  is  one  where  one 
line  failure  can  be  compensated  by  the  other,  one  router  failure  can  be  compensated  by  the 
other,  and  component  failures  in  the  LAN  can  be  compensated  by  redundant  workstations 
and  LAN  cabling.  Figure  6.3  is  a  recalculation  of  the  Ao  presented  in  the  single-threaded 
model. 
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Figure  6.3.  Dual-Threaded  System.  After  Ref.  [14]. 


In  this  example,  the  Ao  of  the  line  remains  99.7%.  This  means  that  the  probability  of 
feUure  is  .3%,  or  0.003.  Since  we  now  have  two  lines  working  together,  either  of  which 
being  up  represents  success,  we  then  have  a  probability  of  failure  of  0.003  x  0.003,  or 
0.00009.  This  means  that  the  line  now  has  a  combined  Ao  of  0.999991.^  By  adding  yet 
a  third  line,  while  maintaining  independence  of  mode  of  failure,  our  model  would  have  an 
Ao  of  0.9999997.  This  graphically  illustrates  the  importance  of  redundant  lines.  In 
summary,  the  procedure  involves: 

•  compute  the  probability  of  failure  (1-Ao). 

•  multiply  the  probabilities  of  failure  for  all  parallel  systems. 

•  convert  back  to  Ao  by  subtracting  the  probability  of  failure  from  1 . 


*  When  computing  Ao,  engineers  count  the  number  of  “nines”.  In  this  example,  we  have  five  “nines”. 
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This  procedure  should  be  performed  on  each  module  in  the  model,  including  the  line,  the 
router,  and  the  LAN.  In  our  model,  shown  in  Figure  6.3,  we  get  an  Ao  for  the  pair  of 
routers  of  six  ‘hines”,  and  for  the  cross-connected  LANs  we  get  an  Ao  of  four  ‘hines”. 
To  compute  the  overall  Ao  for  this  system,  we  simply  multiply  the  three  Ao  values  as; 

Ao  system  =  Ao  WAN  (line)  x  Ao  routers  x  Ao  LANs 
=  0.99999  X  0.999999  x  0.9999 
=  0.999889 

By  using  the  same  method  and  hypothetical  component  values  illustrated  in  Figure  6.2,  we 
compute  the  predicted  down  time  and  get  about  five  minutes  of  down  time  per  month. 
This  is  quite  a  dramatic  difference  fi’om  the  down  time  computed  for  the  single-threaded 
system,  the  results  due  in  large  part  to  the  redundancy  concept.  [Ref  14] 

C.  FUNDAMENTAL  COMPUTATIONS:  THE  SIGNIFICANCE  OF  Ao  VALUES 

Although  the  values  used  for  the  models  presented  in  this  chapter  are  hypothetical, 
they  are  probably  not  too  far  fi'om  realistic  values.  While  the  single-threaded  system  Ao 
of  0.986  may  be  acceptable  for  a  typical  office-automation  environment,  it  is  definitely  not 
acceptable  for  mission  critical  environments  such  as  C3I,  combat,  or  medical.  By 
eliminating  the  single  points  of  failure,  the  Ao  values  shoot  up  to  about  four  or  five 
“nines”.  [Ref  14] 

The  difference  in  down  time  between  systems  that  exhibit  two  ‘hines”  versus  four 
or  five  ‘hines”  has  been  demonstrated.  The  bottom  line  is  simple  -  plan  on  dual-threading 
your  system.  It  provides  the  greatest  availability  possible. 


VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

1.  Importance  of  Analyzing  Data  Traffic 

This  research  has  shown  the  importance  of  anal5?zing  network  data  traffic.  The 
main  issue  pertaining  to  the  installation  of  the  WWW  servers  was  shown  to  be  the 
bandwidth  of  the  existing  network  WAN  links,  and  whether  or  not  the  existing  links  were 
properly  sized  and  able  to  support  the  traffic  load  placed  on  the  network  by  the  users. 
Data  traffic  from  the  five  WAN  links  out  of  NMIMC  was  collected  and  analyzed.  The 
incoming  and  outgoing  traffic  flows  were  reviewed,  and  the  reliability  of  the  lines  were 
checked.  The  load  values  were  analyzed,  evaluated,  and  plotted.  The  data  plots  were 
quite  graphical  in  the  sense  that  they  pointed  out  the  importance  of  looking  beyond  the 
mean  traffic  load  rates  to  the  peak  load  rates.  Spikes  in  the  utilization  rates  were 
evaluated.  Those  lines  that  were  shown  to  peak  above  the  industry  threshold  of  80 
percent  need  to  be  properly  sized  prior  to  the  implementation  of  the  WWW  servers  onto 
the  networks  currently  in  place  at  the  MTF’s. 

2.  Stay  Current  with  Technological  Changes 

Technology,  as  applied  to  the  health  care  field,  that  involves  the  use  of  computers 
and  information  systems,  continues  to  grow  at  a  rapid  pace.  It  is  difficult  to  keep  an 
organization  running  efficiently  if  administrators  do  not  stay  current  with  respect  to  the 
technology  employed  in  their  field.  To  offer  an  organization  the  best  support  possible,  to 
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as  many  users  as  possible,  administrators  must  be  aware  of  the  technology  around  them. 
They  must  evaluate  the  market  leaders.  They  must  stay  abreast  of  the  network 
communication  services  that  both  local  and  national  providers  have  to  offer,  such  as 
ISDN,  Frame  Relay,  ATM,  and  ADSL,  which  are  described  in  short  detail  in  Appendix  E. 
If  administrators  are  current  in  their  field,  they  are  in  excellent  position  to  achieve 
successful  changes  for  their  organizations.  Chapter  V  illustrated  the  direction  that  the 
health  care  field  is  heading  with  respect  to  computers,  the  internet,  and  the  WWW.  Those 
organizations  that  fail  to  stay  current  with  the  technological  changes  within  their  field  will 
fall  behind  and  lose  their  competitive  advantage,  and  will  not  be  able  to  provide  the 
support  they  need  to  survive. 

3.  Continual  and  Proactive  Data  Monitoring 

The  process  of  analyzing  your  network  traffic  should  be  performed  on  a  daily 
basis,  rather  than  quarterly,  or  weekly.  By  keeping  a  constant  pulse  on  network  traffic 
utilization  rates,  organizations  can  ensure  that  they  are  positioned  to  make  the  necessary 
upgrades  quickly,  based  on  facts,  and  eliminate  a  lot  of  the  guess  work  that  they  are 
currently  faced  with  when  trying  to  compute  the  bandwidth  they  really  need  to  support 
their  data  flows.  Organizations  should  adopt  a  data-driven  decision  management 
philosophy  regarding  the  rightsizing  of  vital  communication  links;  they  should  let  the  data 
assist  them  in  making  decisions  regarding  strategic  positioning  and  rightsizing  of  their 
WAN  links.  Finally,  by  adopting  a  proactive,  rather  than  reactive,  policy  on  managing  IT 
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assets,  organizations  can  keep  their  vital  information  flowing,  and  provide  the  strategic 
advantage  they  need  to  yield  the  best  support  possible  to  their  customers. 


B.  RECOMMENDATIONS 

The  evaluation  of  the  WAN  links  at  NMCMC  is  intended  to  be  used  as  a  model  for 
all  sites.  This  research  lead  to  the  following  recommendations: 

•  Deploy  a  network  management  platform  to  all  MTF’s  currently  connected  to 
the  internet. 

•  Train  staffs  in  the  use  of  the  network  management  platform. 

•  Perform  load  balancing  at  the  sites  that  have  redundant  links. 

•  Rightsize  the  individual  links  according  to  the  need  specifled  by  the  data. 

•  Implement  data-driven  decision  management;  let  the  data  assist  managers  and 
network  administrators  in  rightsizing  the  Wan  links. 

•  Investigate  the  possibility  of  transmitting  FTP  traffic  during  non-peak  times. 

•  Investigate  the  possibility  of  conserving  internet  bandwidth  by  caching  hard-hit 
Home  Pages  or  other  popular  pages.  The  caching  can  speed  access  and 
reduce  the  need  to  buy  more  internet  bandwidth  [Ref  26]. 

•  Monitor  network  traffic  on  a  daily  basis. 

•  Stay  current  with,  technology. 

•  Be  proactive;  analyze  the  network  traffic  and  take  action  to  eliminate  problem 
areas  before  they  cause  network  bottlenecks. 

•  Challenge  old  paradigms;  the  technology  is  available  to  make  sound  changes, 
both  technically  and  managerial,  that  assist  administrators  in  maintaining  the 
competitive  advantage  their  organizations  need  to  survive  and  thrive  in  their 
field. 


C.  SUGGESTION  FOR  FURTHER  RESEARCH 

Although  this  research  is  important  to  organizations  in  analyzing  their  WAN  links, 
it  falls  short  in  providing  a  model  for  forecasting  future  traffic  growth.  Ideally,  an 
enterprise  network  capacity  plan  should  include  potential  changes  and  an  anticipated 
traffic  growth  rate  parameter.  The  author  recommends  using  a  network  simulation 


planner,  or  application,  to  assist  in  this  research.  The  equation  for  properly  computing 
traffic  growth  should  include  current  traffic  loads  plus  anticipated  traffic  growth.  This 
should  ensure  a  more  precise  measurement  of  an  organizations  needs,  and  should  better 
position  an  organization  to  provide  the  best  support  for  their  users,  which  in  turn  equates 
to  a  higher  efficiency  rating  and  success  of  the  organization. 
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APPENDIX  A.  HEALTH  AFFAIRS  DIRECTIVES 

A.  BACKGROUND 

In  an  effort  to  provide  enhanced  electronic  information  interchange  (EH)  within 
the  Military  Health  Support  System  (MHSS),  the  Assistant  Secretary  of  Defense  for 
Health  Affairs  (ASD/HA)  has  initiated  guidelines  for  implementing  a  global  information 
system  utilizing  the  internet  and  the  World  Wide  Web  (WWW)  [Ref.  1], 

In  support  of  this  initiative,  ASD/EA  has  agreed  to  fund  the  deployment  and 
operation  of  ASD/HA  Internet  /Web  servers  to  various  DoD  MTFs.  Funds  will  be 
transferred  from  HA  to  the  three  Services.  Each  Service  then  assumes  the  responsibihty 
of  funding  the  design,  implementation,  and  operation  of  Intemet/Web  servers  to  support 
EH  and  web  home  pages  that  will  allow  complete  interoperabihty  across  Health  Affairs, 
the  Surgeons  General,  and  MTFs.  [Ref  1] 

The  Naval  Medical  Information  Management  Center  (NMIMC),  located  in 
Bethesda,  Maryland,  was  established  to  design,  deploy,  and  support  naval  medical 
information  management  systems  and  telecommunications  infrastructure.  The  inherent 
nature  of  NMIMC  makes  it  uniquely  qualified  to  accept  the  responsible  for  the  assigned 
task  of  deploying  the  Navy’s  WWW  servers. 
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B.  MISSION  NEED  STATEMENT 

The  Bureau  of  Medicine  and  Surgery  (BUMED)  has  embraced  the  use  of  the 
WWW  technologies  for  the  dissemination  of  information  throughout  the  claimancy.  It  is 
crucial  that  Navy  healthcare  providers  have  access  to  the  latest  information  on  topics 
ranging  from  policy  and  administrative  procedures  to  headquarters  and  MTF  staffing 
rosters. 

The  ASD/HA  has  initiated  larger-scale  programs  to  support  Eli,  however, 
BUMED  has  immediate  information  dissemination  requirements  and  emerging  technology 
management  issues  that  must  be  addressed  by  NMCMC.  The  system  proposed  under  the 
NMIMC  abbreviated  system  decision  paper  (ASDP)  will  meet  these  requirements  while 
allowing  seemless  interaction  of  Navy  Medical  home-pages  with  other  MHSS  components 
as  directed  by  ASD/HA  [Ref  2] 


C.  TASKING 

NMIMC  has  been  charged  with  design,  deployment  and  support  of  Naval  medical 
information  systems  and  telecommunications  infrastructure.  The  objective  of  the  task 
statement  (Statement  of  Work  (SOW))  is  to  acquire  support  for  the  design,  testing, 
implementation,  installation,  and  training  of  the  WWW  system  that  is  being  deployed  by 
NMIMC. 

The  existing  Navy  Medical  Department  Network  will  be  used  as  the  infrastructure 
to  support  data  transmissions  from  the  WWW  servers.  This  network  is  classified  as  a 
Wide  Area  Network  (WAN),  and  was  installed  by  a  major  effort  know  as  the  Medical 
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Open  Architecture  (MED-OA)  Project.  Figure  A.1  shows  the  Metropolitan  Area 
Networks  that  are  in  place  to  support  Navy  Medical  administrative  needs. 


Figure  A.1.  Navy  Medical  Department  Network. 


Specific  technical  details  surrounding  this  network  will  not  be  presented  here,  other  than 
to  say  that  the  WAN  links  are  of  various  bandwidths,  ranging  from  56Kb  (56  thousand 
bits  per  second)  to  T-1  speeds  (1.544  million  bits  per  second).  This  is  of  importance  to 
the  WWW  server  acquisition  initiative,  as  the  bandwidth  in  many  locations  may  not  be 
appropriate  for  the  anticipated  increase  in  data  traffic  due  to  the  addition  of  the  WWW 
servers  onto  the  existing  network.  These  WAN  links  must  be  analyzed  for  data  traffic 
flow  and  congestion,  and  rightsized  as  deemed  necessary.  This  is  perhaps  the  single  most 
important  technical  aspect  of  this  initiative,  and  is  addressed  in  the  statement  of  work. 
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The  contractor  shall  perform  all  services  prescribed  in  SOW  at  the  tentative 
locations  listed  in  Table  A.1,  which  are  subject  to  change  at  the  discretion  of  NMIMC. 
[Ref  18] 


Server  &  Related  Sites  Listings 

Location 

1.  NAVMEDINFOMGMTCEN 

Bethesda,  MD 

2.  Washington  BUMED  HQ 

Washington,  DC 

3.  NMQMC  DET/East  Coast  MTFs 

Norfolk,  VA 

4.  NMIMC  DETAVest  Coast  MTFs 

San  Diego,  CA 

5.  Tricare  Region  Nine 

San  Diego,  CA 

6.  Tricare  Region  Two 

Portsmouth,  VA 

7.  Great  Lakes  NH 

Chicago,  IL 

8.  Groton  NH 

Groton,  CT 

9.  Bremerton,  NH 

Seattle,  WA 

10.  Pensacola  NH 

Pensacola,  FL 

Table  A.1.  Projected  WWW  Server  Locations. 


D.  STATEMENT  OF  WORK  FOR  BUMED  WWW  SERVICES 

In  an  effort  to  be  consistent  with  National  Health  Care  Reform,  the  MHSS  is 
embarking  on  a  major  program  of  health  care  reform  called  TRICARE.  TRICARE  is 
designed  to  ensure  the  most  effective  execution  of  the  military  care  mission,  recognizing 
the  need  to  ensure  access  to  a  quality  health  care  benefit,  control  cost,  and  respond  to 
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changing  national,  military,  and  health  care  priorities.  A  major  feature  of  TRICARE  is  the 
division  of  the  United  States-based  MHSS  into  twelve  Health  Service  Regions,  each 
headed  by  a  medical  center  commander  designated  as  the  Lead  Agent,  who  has  broad, 
new  responsibilities  for  health  care  management  throughout  the  region.  The  department 
of  the  Navy  BUMED,  the  TRICARE  Lead  Agents,  and  MTFs  have  a  critical  need  to  be 
able  to  exchange  and  disseminate  textual  and  graphical  information  concerning  TRICARE 
policy,  planning  and  execution,  and  medical  information  (including  that  which  can  be 
acquired  from  on-line  sources  such  as  Medline).  [Ref  19] 


E.  REQUIRED  RESOURCES/SCOPE  OF  WORK 

The  contractor  has  been  requested  to  perform  the  following  services:  [Ref  20] 

•  Develop  Detailed  Implementation  Plan.  The  contractor  shall  develop  a  project 
plan  that  describes  tasks,  subtasks,  and  schedules;  identifies  members  of  the 
team,  including  areas  of  responsibility;  and  describes  methods  to  be  used  to 
implement  the  project.  The  contractor  will  present  a  work  breakdown 
structure  providing  detail  regarding  interim  deliverables,  resources,  milestones, 
and  schedule  for  the  project.  This  plan  may  be  modified  as  the  tasks  progress 
and  the  environment  changes.  It  will  be  approved  by  the  Task  Monitor. 

•  Implement  WWW  Home  Pages.  The  contractor  shall  develop  a  WWW  Home 
Page  application  for  BUMED,  NMIMC,  Lead  Agent  Regions  2  and  9,  and 
NMIMC  Detachments  in  San  Diego  and  Portsmouth,  consistent  with  the 
guidelines  developed  by  Health  Affairs.  Continuous  user  feedback  will  be  a 
critical  part  of  the  development  effort.  The  home  pages  and  each  subsequent 
pages  A^l  be  fielded  for  ‘beta”  testing  within  NMIMC  before  release  to  the 
internet. 

•  Conduct  Hvper-Text  Markup  Language  tHTML^  Conversion,  The  contractor 
shall  convert  key  documents  into  HTML.  It  is  assumed  that  all  documents  will 
be  in  an  industry  standard  word  processing  format,  i.e.  WordPerfect,  Microsoft 
Word,  ASCn,  etc.  The  number  of  documents  and  the  extent  to  which  each 
document  will  contain  ‘hyper-links”  will  be  dependent  on  the  period  of 
performance. 
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Specific  tasks  to  be  provided  by  the  contractor  include:  [Ref.  19] 

•  Conduct  Site  Surveys 

•  Develop  detailed  implementation  plan 

•  PPP/SLIP  server  configuration 

•  Implement  WWW  Home  Pages 

•  Conduct  Hyper-Text  Markup  Language  (HTML)  Conversion 

•  Design  Target  System 

•  Develop  Support/Training  Plan 

•  Domain  Name  Service  (DNS)  Upgrade  Study 

•  Deploy  Servers 

•  Conduct  Training 

•  Develop  USENET  Plan 

•  Implement  USENET  Capabilities 

•  Deploy  Browsers 

•  Operate  and  Maintain  Home  Pages 


Specific  deliverables  to  be  provided  by  the  contractor  include:  [Ref  19] 

•  Detailed  Implementation  Plan 

•  Communication  Upgrade  Study 

•  BUMED  WWW  Home  Pages 

•  Key  Documents  in  HTML  Format 

•  Target  System  Specifications 

•  Support/Training  Plan 

•  Training  Material  and  Documentation 

•  Site  Survey  Reports 

•  USENET  Plan 

•  Operation  and  Maintenance  Home  Pages 


F.  CONTRACT  VEHICLE 

Initially,  the  proposed  systems  were  planned  on  being  acquired  via  the  following 
procurement  options,  where  feasible: 

•  GSA  Schedule 

•  Existing  Procurement  Contracts 

•  Open  Market 

•  A  combination  of  the  above  options 
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Where  those  options  are  not  available,  or  where  high  tech  or  highly  specialized  items  are 
required  but  not  available  on  existing  contracts,  procurement  will  be  accomplished 
through  the  establishment  of  an  8(a)  contractor.  [Ref  2] 

The  contract  vehicle  that  happened  to  be  available  to  NMIMC  was  the 
D/SIDDOMS  contract.  The  acronym  stands  for  Defense  Medical  Information 
Systems/Systems  Integration,  Design,  Development,  Operations,  and  Maintenance.  This 
contract  is  dated  10  March,  1996,  and  is  managed  by  the  United  States  Army’s  Defense 
Medical  Program  Activity  managers,  who  are  based  in  Skyline,  Virginia.  The  Initiating 
Proponent  is  the  Office  of  the  Assistant  Secretary  of  Defense  for  Health  Affairs.  [Ref  21] 
The  Contracting  Agency  for  the  Army  is  the  Defense  Supply  Service,  Washington 
DC.  There  are  approximately  600  support  personnel  assigned  in  various  satellite  offices, 
including  the  Pentagon,  who  handle  all  task  orders  and  support  for  this  contract.  [Ref  21] 
The  D/SIDDOMS  contract  is  also  a  provider  of  components  for  one  of  the  DoDs 
major  projects,  the  Composite  Health  Care  Systems  project,  which  provides  numerous 
services  such  as  patient  appointments  and  scheduling,  patient  administration,  and  email 
service  to  various  MTF  departments.  Other  major  Navy  projects  that  are  using  the 
D/SIDDOMS  contract  vehicle  include  [Ref  21]: 

•  Systems  Integration  Project 

•  Automated  Information  Security  Project 

•  Telemedicine  Project 
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The  D/SIDDOMS  is  a  follow-on  contract  to  the  SIDDOMS,  which  ran  for  6-7  years  prior 
to  the  signing  of  the  new  contract.  The  type  of  equipment  and  services  offered  by  the 
D/SIDDOMS  contract  are  vast,  and  include  any  IT  related  elements  such  as: 

•  Hardware 

•  Software 

•  Planning  and  Development 
.•  Prototyping 

•  Support  Services 

•  Maintenance 

There  are  three  lots  available  on  the  D/SIDDOMS  contract  [Ref  21].  They  are  listed  as: 

•  Loti 

-  System  Design,  Development,  Operations,  Maintenance,  and  Support 

-  Contractors  include:  AMS,  EDS,  PRC,  SAIC 

-  Ceiling  is  $325M 

•  Lot  n 

-  Systems  Integration,  Oversight,  Requirements  Development,  Concept 
Development 

-  Contractor:  Northrop  Grumman 

-  Ceiling  is  $50M 

•  Lot  in 

-  Studies  and  Analysis 

-  Contractors:  Birch  and  Davis,  Solon  Consulting,  United  Health  Care, 

Vector  Research 

-  Ceiling  is  $25M 

•  POC  for  Lot  I  &  H:  Ms.  JuUe  Phillips  (703)  681-6903 

•  POC  for  Lot  in:  Ms.  Brenda  Mabrey  (703)681-8720  [Ref  22] 
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The  authors’  understanding  is  that  the  D/SIDDOMS  contract  is  a  Requirements  Contract, 
which  is  defiined  as; 

A  requirements  contract  provides  for  filling  all  actual  purchase  requirements  of 
designated  government  activities  for  specific  supplies  or  services  during  a  specified 
contract  period,  with  deliveries  to  be  scheduled  by  placing  orders  with  the 
contractor.  This  type  is  used  when  the  government  anticipates  recurring 
requirements,  but  can  not  predetermine  the  precise  quantities  of  supplies  or 
services  that  will  be  needed  during  a  definite  period.  Funds  are  obligated  by  each 
delivery  order,  not  by  the  contract  itself  [Ref  23] 

The  NMIMC  proposal  is  to  procure  the  following  components  fi'om  the  D/SIDDOMS 

contract  [Ref  8]: 

•  Hardware,  i.e.,  WWW  servers 

•  Software,  i.e.,  web  browser(s) 

•  Labor,  to  include: 

1.  Deployment 

2.  Communication  lines/WAN  analysis 

3.  Cisco  router  administration/management 

4.  User  training 

5.  Maintenance 

6.  System  Support 


G.  PROPOSED  SOLUTION 

The  proposed  solution  is  to  design,  engineer,  procure,  test,  deploy,  and  operate  a 
WWW  server  suite  at  NMIMC  that  supports  the  BUMED  Headquarters,  NMIMC,  and 
the  Washington  DC  region.  Similar  installations  will  be  performed  at  the  NMIMC 
Detachments  to  support  both  the  Eastern  and  Western  regions.  The  WWW  servers  will 
support  home  pages  and  administrative  systems  for  BUMED,  NMIMC,  and  other  MTFs. 
The  system  will  support  interfaces  to  on-line  medical  resources  like  Medline,  organize  and 
index  medical  resources  on  the  Internet,  and  provide  workgroup  tools  for  information 
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sharing  among  functional  groups.  Enhanced  Internet  connectivity  will  be  provided  to  each 
site  as  required  to  support  the  increased  network  trafiBc  anticipated  with  the  introduction 
of  the  WWW  service.  This  solution  will  allow  system  components  to  be  managed  from 
NMIMC  network  management  systems.  Additionally,  the  proposed  solution  will 
incorporate  a  facility  to  manage  access  to  systems  with  restricted  access  and  to  control 
access  to  the  Internet  at  large.  [Ref  2] 

Selected  systems  will  use  commercial-off-the-shelf  (COTS)  hardware  and 
software.  Advanced  functionality  will  require  some  software  customization.  The 
emphasis  of  this  system  is  not  on  software  development,  but  on  providing  the  platform, 
structure,  tools,  and  management  support  for  individuals  and  organizations  throughout  the 
claimancy  to  easily  maintain  information  content  and  build  additional  functionality. 

[Ref  2] 

H.  ALTERNATIVES  CONSIDERED 

1.  Maintaining  the  Status  Quo 

This  alternative  will  not  provide  the  EH  capabilities  dictated  by  ASD/HA  and  will 
not  address  the  information  dissemination  requirements  of  BUMED,  NMIMC,  and  the 
MTFs.  Therefore,  this  alternative  is  deemed  unacceptable.  [Ref  2] 
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2.  Central  Claimancy  Master  Server  Implementation 

This  solution  would  locate  all  system  resources  in  a  single  location,  rather  than 
distributing  systems  across  major  regions.  A  central  solution  would  cost  less  but  is  not 
desirable  for  the  following  reasons: 

•  loss  of  local  ownership  would  impact  local  information  sharing  and  reduce  the 
usefulness  of  the  system 

•  single  point  of  failure  and  loss  of  service  redundancy 

•  communications  requirements  and  Internet  connectivity  overly  taxing  oat 
central  host  location 

It  should  be  noted  that  some  degree  of  centralization  is  achieved  under  the  proposed 
solution,  primarily  by  having  claimancy-wide  standards  and  an  organized  methodology  for 
information  sharing  and  dissemination.  [Ref  2] 


L  COSTS  AND  BENEFITS 

The  life  cycle  cost  of  the  alternatives  are  described  below  [Ref  2]. 

a.  Maintaining  the  Status  Quo.  This  option  is  not  shown  since  it  is  not  an 
acceptable  alternative  as  it  fails  to  meet  mission  requirements. 

b.  Central  Claimancy  Master  Server  Implementation. 

The  life  cycle  costs  of  the  alternative  centralized  solution  are  shown  in  Table  A.2. 
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COSTS:  ($0,000) 

FY96 

FY97 

FY98 

FY99 

FYOO 

TOTAL 

SYSTEM  HW&SW 

$500 

$30 

$0 

$0 

$0 

$530 

Installation  &  Maintenance 

190 

45 

45 

45 

45 

370 

Operations 

600 

600 

450 

450 

400 

2500 

Total  ($0,000) 

$1290 

$675 

$495 

$495 

$445 

$3400 

Table  A.2.  Life  Cycle  Costs  of  Centralized  Solution.  From  Ref  [2]. 


c.  Proposed  Solution 

The  life  cycle  costs  of  the  proposed  BTJMED/NMIMC  solution  are  shown  in  Table 


A.3. 

Costs  assumptions  are  based  on  [Ref  2]; 

•  2  high  capacity  WWW  production  servers  and  1  development  server  (35K  per) 

•  2  high  capacity  WWW  production  multimedia  and  application  link  servers  and  1 
development  server  (15K  per) 

•  software  for  the  above  servers  includes  development  and  monitoring  tools,  and 
database/application  interface  software  (75K) 

•  Installation,  operational  support  and  other  personnel,  WWW  expertise  for 
server/communications  installation  and  ongoing  operations,  and  programming  and 
design  are  all  outsourced.  Each  of  the  four  production  systems  are  assumed  to  require 
5K  of  installation  and  approximately  lOK  of  operational  support  per  year 
(development  systems  require  5K  of  installation  and  5K  of  operational  support  per 
year).  Programming  and  design  support  is  assumed  to  be  35K  per  server  in  the  initial 
2  years,  tapering  down  in  the  out  years. 
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Costs:  ($0,000) 

FY96 

FY97 

FY98 

FY99 

FYOO 

Total 

System  Servers 

150 

0 

0 

0 

0 

150 

Server  Software 

75 

0 

10 

0 

10 

95 

Conuns  Hardware 

40 

0 

0 

0 

0 

40 

Maintenance 

0 

10 

10 

10 

10 

40 

Supplies 

3 

3 

3 

3 

3 

15 

Installation 

25 

0 

0 

0 

0 

25 

Training 

8 

15 

10 

0 

0 

33 

Hardware  Upgrade 

8 

15 

25 

20 

10 

78 

Software  Upgrade 

0 

12 

20 

15 

10 

57 

Site  Prep 

20 

0 

0 

0 

0 

20 

Internet  Comms 

55 

55 

45 

45 

40 

240 

Operational 

45 

50 

50 

35 

35 

215 

Personnel 

140 

140 

no 

50 

50 

490 

Total  ($0,000) 

569 

300 

283 

178 

168 

1498 

Table  A.  3.  Life  Cycle  Costs  of  Proposed  Solution.  From  Ref  [2]. 


J.  BENEFITS  OF  PROPOSED  SOLUTION 

Electronic  information  interchange  within  BUMED  will  meet  the  goals  of 
optimizing  communications  flow  and  will  meet  the  requirements  for  connectivity  within 
MHSS  as  dictated  by  ASD/HA.  The  regional  approach  to  WWW  server  deployment  will 
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maximize  the  local  control  and  therefore,  maximize  the  use  and  benefits  of  the  technology 
while  minimizing  central  support  costs.  pRef  2] 


Additionally,  the  claimancy  will  benefit  from  improved  decision  making  due  to 
higher  quality  information  being  delivered  to  the  appropriate  decision  maker  when  and 
where  needed.  The  claimancy  will  also  benefit  firom  increased  availability  of  training  and 
readiness  resources,  which  will  help  develop  better  prepared  decision  makers.  Improving 
the  preparedness  and  capabilities  of  Navy  medical  decision  makers  will  result  in  higher 
quality  health  care  delivered  to  the  customer.  [Ref  2] 


K  FUNDING  ISSUES 

The  author  had  the  distinct  pleasure  of  meeting  Major  Fred  Peters,  USAF,  at  the 
American  Academy  of  Medical  Administrators  (AAMA)  conference  that  was  held  in 
Irvine,  CA,  in  November,  1995.  Major  Peters  is  the  Chief  of  Operations  for  Defense 
Medical  Information  Management,  Office  of  the  ASD/HA.  He  presented  a  briefing  for  the 
AAMA  regarding  the  status  of  Health  Affairs  Information  Systems.  Afterwards,  the 
author  and  Major  Peters  briefly  discussed  the  issues  surrounding  this  thesis  -  which  deal 
with  analyzing  the  WAN  links  at  NMIMC  -  since  it  is  directly  tied  to  the  WWW  server 
implementation  plan.  During  this  conversation.  Major  Peters  stated  that  the  funding  for 
the  WWW  server  components  would  be  provided  by  the  ASD/HA.  He  further  explained 
that  ASD/HA  would  transfer  the  fimds,  via  a  Military  Inter-service  Procurement 
Requirement  (MIPR),  to  the  individual  DoD  agents,  who  in  turn  would  be  responsible  for 
procuring  their  own  components  for  the  WWW  server  project. 


In  January,  1996,  the  author  again  had  the  fortune  of  meeting  Major  Peters  at  the 
Healthcare  Information  Management  Systems  Society  (HEMSS)  conference  in  Atlanta, 
Georgia.  The  ensuing  discussion  centered  around  the  MIPR,  and  Major  Peters  confirmed 
that  the  MIPR  action  had  already  taken  place  between  the  ASD/HA  and  the  Services. 

Therefore,  once  the  components  ordered  on  the  individual  delivery  orders  are 
received  by  the  Navy  MTFs  and  the  invoices  are  certified,  payment  will  be  made  by 
NMIMC  fi-om  the  funds  MDPRed  fi-om  the  ASD/HA  and  earmarked  for  the  WWW  server 
initiative. 
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APPENDIX  B.  UNIX  SCRIPTS 


A.  CRON  ENTRY 

The  cron  entry  is  also  known  as  a  daemon  process.  A  daemon  is  a  process  that 
executes  ‘in  the  background”  either  waiting  for  some  event  to  occur,  or  waiting  to 
perform  some  specified  task  on  a  periodic  basis.  The  cron  entry  is  a  standard  Unix 
process  that  performs  periodic  tasks  at  given  times  during  the  day,  taking  its  instructions 
from  the  file/usr/lib/crontab.  The  cron  entry  shown  below  defines  when  the  data  is  to  be 
sampled.  In  our  case,  the  data  was  requested  every  30  minutes.  [Ref  24] 

cron  entry: 

/usr/dsc3cjc/testl  |  egrep  '(=|EDTlprotocollMTU|minute)' 

/usr/dsc3cjc/trovini 

This  script  basically  performs  an  iterative  process  at  the  specified  time  interval.  The  shell 
goes  to  the  /usr/dsc3cjc/testl  script,  performs  that  function,  and  returns  to  the  cron  script. 

The  remaining  portion  of  the  cron  entry  uses  pipes  (j)  and  the  egrep  command  to 
perform  specific  operations  on  the  data  prior  to  dumping  the  results  into  the 
/usr/dsc3cjc/trovini  file. 

Pipes  allow  you  to  connect  two  commands  together  so  the  output  firom  one 
program  becomes  the  input  of  the  next  command.  The  egrep  command  is  simply  an 
extended  version  of  the  grep  command.  The  grep  command  means  “globally  search  for  a 
regular  expression  and  print  all  lines  containing  it.  A  regular  expression  combines  a 
string  of  text  with  some  special  characters  used  for  pattern  matching.  Therefore,  the  grep 
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is  used  within  the  pipe  so  that  only  those  lines  of  the  input  files  containing  a  given  string 
are  sent  to  the  standard  output.  [Ref  4] 

For  more  information  about  Unix  commands,  you  should  refer  to  any  Unix  book 
or  manual.  More  detailed  explanations  at  this  point  would  just  cloud  the  issue,  and  you 
need  to  stay  focused  on  the  basic  process  here,  which  is  leading  up  to  the  plotting  of  the 
traffic-data,  or  more  specifically,  the  utilization  rates. 


B.  TBDE  TESTl  SCRIPT 

After  the  time  sequencing  is  assigned,  the  shell  goes  to  the 
/usr/dsc3cjc/testl  file.  The  testl  script  is  shown  below. 


testl: 

echo "  .  " 

date 

echo  "  ■  -  - 

telnet  <  /usr/dsc3cjc/tn.cmd  & 
sleep  15 
kill  -9  $! 


Once  in  testl,  the  process  is  told  to  echo  (regenerate)  the  ‘^==“  lines  that  surround  the 
date.  This  command  prints  the  lines  onto  the  screen,  allowing  the  time  to  stand-out  from 
the  other  data  to  make  it  easier  to  distinguish  the  time  intervals.  After  the  testl  script 
echoes  the  second  ‘^=“  line,  the  shell  telnets  into  the  /usr/dsc3cjc/tn.cmd  script,  where  it 


performs  that  operation,  and  returns  to  the  testl  script. 


The  ampersand  (&)  is  used  to  specify  a  background  process.  It  allows  the  kernel 
(the  operating  system  nucleus),  the  program  in  charge  of  the  Unix  system,  to  synchronize 
two  or  more  processes  running  concurrently.  By  using  the  &,  you  are  telling  the  kernel  to 
execute  a  command  while  the  login  shell  is  doing  something  else.  [Ref.  25] 

In  our  case,  that  something  else  is  sleeping  for  15  seconds  so  that  the  telnet  session 
can  run.  Once  the  tn.cmd  is  done,  the  kill  -9  command  kills  the  background  shell  (telnet 
session).  The  $!  variable  is  used  to  hold  the  process  ID  (PID)  of  the  last  process  run  in 
the  background;  it  is  used  to  notify  the  shell  which  process  to  kill. 

C.  THE  TN.CMD  SCRIPT 

As  mentioned  earlier,  after  the  testl  script  echoes  the  second  ‘^==“  line, 

the  shell  telnets  into  the  /usr/dsc3cjc/tn.cmd  script,  which  is  shown  below.  This  sidestep 

simply  opens  a  session  with  the  131.158.50.50  device,  which  is  the  Cisco  7000  router,  and 

asks  it  to  show  the  interfaces  of  the  five  WAN  links.  The  “~q”  command  tells  the  tn.cmd 

script  to  exit  and  returns  to  the  testl  script.  The  ‘kros”  command  is  the  super-secret 

mystery  password  that  the  technical  engineer  uses  to  gain  access  to  the  router. 

tn.cmd: 

escape 

open  131.158.50.50 
aros 

sho  int  serial  4/1  , 

sho  int  serial  4/4 

sho  int  serial  4/5 

sho  int  serial  4/7 

sho  int  fddi  2/0 

~q 
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APPENDIX  C.  SAS  SCRIPT 


Chapter  n  introduced  the  SAS  script  that  was  generated  to  extract  the  dates  and  time  of 
the  observations,  the  link  names,  and  the  load  values  from  the  individual  data  files  so  that  a 
statistical  analysis  could  be  performed  on  the  data.  The  following  script  was  written  to 
accomplish  that  goal  [Ref  6]. 


options  linesize=80; 

filename  kevin  '/h/josliua_n3/kltrovin/tliesis/cat.dat'; 

data  one  (drop=  si  s2  s3  s4  s5  s6  s7  s8  s9  slO  sll  sl2  five 

dl  d2  d3  d4  d5  d6  d7  d8  d9  dlO  dll  dl2 

el  e2  e3  e4  e5  e6  e7  e8  e9  elO  ell  el2 

fl  f2  f3  f4  £5  f6  f7  f8  f9  no  fll  fl2 

gl  g2  g3  g4  g5  g6  g7  g8  g9  glO  gll  gl2); 

infile  kevin ; 


input 


#2 


day$ 

months 

dates 

todS 


#5 


#9 


s5S 

slOS 

Sis 

s6  S 

sllS 

s2S 

s7S 

sl2S 

s3S 

s8  S 

loadl  S 

s4S 

s9S 

d5S 

dlOS 

dlS 

d6S 

dllS 

d2S 

d7S 

dl2S 

d3S 

d8S 

load4  S 

d4S 

d9S 
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#13 


el$ 
e2$ 
e3  $ 
e4$ 


e5$ 

elO$ 

e6  $ 

ell$ 

e7$ 

el2$ 

eS  $ 

loads  $ 

e9$ 

#17 

fl$ 
f2$ 
f3  $ 
f4$ 


f5$ 

flO$ 

f6$ 

fll$ 

f7$ 

fl2$ 

fS$ 

load7  $ 

f9$ 

gl$ 

g2$ 

g3$ 


g4$ 

g9$ 

g5$ 

gio$ 

g6$ 

gll$ 

g7$ 

gl2$ 

g8$ 

loadfddiS 

#23  five  $; 


nloadl=  length(loadl); 
iiload4=  length(load4); 
nload5=  length(load5); 
iiload7=  length^oad?); 
nloadf=  length(loadfddi); 

array  nload{5}  nloadl  iiload4  nload5  nload?  nloadf; 
array  xload{5}  xloadl  xload4  xloadS  xload?  xloadf; 
array  load{5}  loadl  load4  loads  load?  loadfddi; 

do  i  =  1  to  5; 

if  iiload{i}=  5  then  xload{i}=(substr(load{i},l,l)/255*100); 
else  if  nload{i}  =  6  then  ?doad{i}=(substr(load{i},l,2)/255*100); 
else  if  nload{i}=7  then  xload{i}=(substr(load{i},l,3)/255*100); 
else  xload{i}=-999; 
end; 

hour  =  sobstr(tod,l,2); 

proc  freq;  tables  xloadl  xload4  xloadS  xload?  xloadf; 
proc  means; 

var  xloadl  xload4  xloadS  xload?  xloadf; 
proc  sort;  by  hour; 
proc  means; 

var  xloadl  xload4  xloadS  xload?  xloadf; 
by  hour. 
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APPENDIX  D.  SAS  DATA  CHARTS 


Chapter  IQ  introduced  the  SAS  charts  that  where  generated  from  the  traffic,  sas 
program  [Ref.  6],  These  charts  show  the  frequency  distributions  and  the  hourly  mean, 
standard  deviation,  minimum  load  values,  and  maximum  load  values  for  the  five  NMIMC 
WAN  links  analyzed  in  this  study.  These  charts  are  provided  in  this  appendk  for 
informational  and  reference  purposes.  The  values  in  these  charts  were  used  to  generate 
the  graphs  introduced  in  chapter  IQ  that  show  the  trends  of  the  data  traffic  for  the  WAN 
links. 


Cumulative 


XLOADl 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 
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57.6 

1359 

57.6 

0.7843137255 

4 
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1363 

57.8 

1.1764705882 

2 

0.1 

1365 

57.9 

1.568627451 

413 

17.5 

1778 

75.4 

3.137254902 

2 

0.1 

1780 

75.5 

3.5294117647 

149 

6.3 

1929 

81.8 

5.0980392157 

87 

3.7 

2016 

85.5 

7.0588235294 

64 

2.7 

2080 

88.2 

8.6274509804 

53 

2.2 

2133 

90.4 

10.588235294 

40 

1.7 

2173 

92.1 

12.156862745 

20 

0.8 

2193 

93.0 

14.117647059 

27 

1.1 

2220 

94.1 

15.68627451 

19 

0.8 

2239 

94.9 

17.647058824 

15 

0.6 

2254 

95.5 

19.607843137 

12 

0.5 

2266 

96.1 

21.176470588 

13 

0.6 

2279 

96.6 

23.137254902 

6 

0.3 

2285 

96.9 

24.705882353 

6 

0.3 

2291 

97.1 

26.666666667 

3 

0.1 

2294 

97.2 

28.235294118 

5 

0.2 

2299 

97.5 

30.196078431 

3 

0.1 

2302 

97.6 

31.764705882 

4 

0.2 

2306 

97.8 

33.725490196 

5 

0.2 

2311 

98.0 

35.68627451 

2 

0.1 

2313 

98.1 

37.254901961 

3 

0.1 

2316 

98.2 

39.215686275 

1 

0.0 

2317 

98.2 

40.784313725 

1 

0.0 

2318 

98.3 

47.843137255 

4 

0.2 

2327 

98.6 

49.803921569 

1 

0.0 

2328 

98.7 

53.333333333 

1 

0.0 

2329 

98.7 

56.862745098 

3 

0.1 

2332 

98.9 

62.352941176 

1 

0.0 

2333 

98.9 

65.882352941 

2 

0.1 

2335 

99.0 

67.843137255 

1 

0.0 

2336 

99.0 

69.411764706 

1 

0.0 

2337 

99.1 

71.37254902 

3 

0.1 

2340 

99.2 

74.901960784 

1 

0.0 

2341 

99.2 

80 

2 

0.1 

2343 

99.3 

81.960784314 

1 

0.0 

2344 

99.4 

83.921568627 

1 

0.0 

2345 

99.4 

85.490196078 

2 

0.1 

2347 

99.5 

87.450980392 

2 

0.1 

2349 

99.6 

90.980392157 

2 

0.1 

2351 

99.7 

92.549019608 

1 

0.0 

2352 

99.7 

94.509803922 

3 

0.1 

2355 

99.8 

96.078431373 

3 

0.1 

2358 

100.0 

98.039215686 

1 

0.0 

2359 

100.0 

Cumulative 


XLOAD4 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 

148 

6.3 

148 

6.3 

1.568627451 

118 

5.0 

266 

11.3 

3.5294117647 

74 

3.1 

340 

14.4 

5.0980392157 

54 

2.3 

394 

16.7 

7.0588235294 

31 

1.3 

425 

18.0 

8.6274509804 

27 

1.1 

452 

19.2 

10.588235294 

16 

0.7 

468 

19.8 

12.156862745 

15 

0.6 

483 

20.5 

14.117647059 

14 

0.6 

497 

21.1 

15.68627451 

23 

1.0 

520 

22.0 

17.647058824 

19 

0.8 

539 

22.8 

19.607843137 

32 

1.4 

571 

24.2 

21.176470588 

36 

1.5 

607 

25.7 

23.137254902 

59 

2.5 

666 

28.2 

24.705882353 

71 

3.0 

737 

31.2 

26.666666667 

76 

3.2 

813 

34.5 

28.235294118 

93 

3.9 

906 

38.4 

30.196078431 

113 

4.8 

1019 

43.2 

31.764705882 

127 

5.4 

1146 

48.6 

33.725490196 

113 

4.8 

1259 

53.4 

35.68627451 

107 

4.5 

1366 

57.9 

37.254901961 

88 

3.7 

1454 

61.6 

39.215686275 

84 

3.6 

1538 

65.2 

40.784313725 

73 

3.1 

1611 

68.3 

42.745098039 

61 

2.6 

1672 

70.9 

96 


44.31372549 

55 

2.3 

1727 

73.2 

46.274509804 

44 

1.9 

1771 

75.1 

47.843137255 

50 

2.1 

1821 

77.2 

49.803921569 

29 

1.2 

1850 

78.4 

51.764705882 

35 

1.5 

1885 

79.9 

53.333333333 

31 

1.3 

1916 

81.2 

55.294117647 

33 

1.4 

1949 

82.6 

56.862745098 

29 

1.2 

1978 

83.8 

58.823529412 

28 

1.2 

2006 

85.0 

60.392156863 

32 

1.4 

2038 

86.4 

62.352941176 

30 

1.3 

2068 

87.7 

63.921568627 

31 

1.3 

2099 

89.0 

65.882352941 

20 

0.8 

2119 

89.8 

67.843137255 

21 

0.9 

2140 

90.7 

69.411764706 

19 

0.8 

2159 

91.5 

71.37254902 

16 

0.7 

2175 

92.2 

72.941176471 

15 

0.6 

2190 

92.8 

74.901960784 

14 

0.6 

2204 

93.4 

76.470588235 

7 

0.3 

2211 

93.7 

78.431372549 

12 

0.5 

2223 

94.2 

80 

17 

0.7 

2240 

95.0 

81.960784314 

17 

0.7 

2257 

95.7 

83.921568627 

12 

0.5 

2269 

96.2 

85.490196078 

8 

0.3 

2277 

96.5 

87.450980392 

8 

0.3 

2285 

96.9 

89.019607843 

9 

0.4 

2294 

97.2 

90.980392157 

13 

0.6 

2307 

97.8 

92.549019608 

16 

0.7 

2323 

98.5 

94.509803922 

16 

0.7 

2339 

99.2 

96.078431373 

15 

0.6 

2354 

99.8 

98.039215686 

4 

0.2 

2358 

100.0 

100 

1 

0.0 

2359 

100.0 

Cumidative 


XLOAD5 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 

1927 

81.7 

1927 

81.7 

0.7843137255 

120 

5.1 

2047 

86.8 

1.1764705882 

81 

3.4 

2128 

90.2 

1.568627451 

61 

2.6 

2189 

92.8 

1.9607843137 

24 

1.0 

2213 

93.8 

2.3529411765 

30 

1.3 

2243 

95.1 

2.7450980392 

30 

1.3 

2273 

96.4 

3.137254902 

18 

0.8 

2291 

97.1 

3.5294117647 

17 

0.7 

2308 

97.8 

3.9215686275 

8 

0.3 

2316 

98.2 

4.3137254902 

6 

0.3 

2322 

98.4 

4.7058823529 

6 

0.3 

2328 

98.7 

5.0980392157 

6 

0.3 

2334 

98.9 

97 


5.4901960784 

3 

0.1 

2337 

99.1 

6.2745098039 

4 

0.2 

2341 

99.2 

6.6666666667 

3 

0.1 

2344 

99.4 

7.0588235294 

3 

0.1 

2347 

99.5 

7.4509803922 

3 

0.1 

2350 

99.6 

8.2352941176 

1 

0.0 

2351 

99.7 

8.6274509804 

2 

0.1 

2353 

99.7 

9.0196078431 

3 

0.1 

2356 

99.9 

9.4117647059 

1 

0.0 

2357 

99.9 

14.901960784 

1 

0.0 

2358 

100.0 

28.62745098 

1 

0.0 

2359 

100.0 

Cumulative 


XLOAD7 

Frequency 

Percent 

Frequency 

Percent 

0.3921568627 

2019 

85.6 

2019 

85.6 

0.7843137255 

111 

4.7 

2130 

90.3 

1.1764705882 

56 

2.4 

2186 

92.7 

1.568627451 

90 

3.8 

2276 

96.5 

1.9607843137 

29 

1.2 

2305 

97.7 

2.3529411765 

16 

0.7 

2321 

98.4 

2.7450980392 

13 

0.6 

2334 

98.9 

3.137254902 

7 

0.3 

2341 

99.2 

3.5294117647 

4 

0.2 

2345 

99.4 

8.6274509804 

1 

0.0 

2346 

99.4 

24.705882353 

1 

0.0 

2347 

99.5 

30.196078431 

1 

0.0 

2348 

99.5 

31.764705882 

1 

0.0 

2349 

99.6 

39.215686275 

2 

0.1 

2351 

99.7 

47.843137255 

1 

0.0 

2352 

99.7 

56.862745098 

1 

0.0 

2353 

99.7 

83.921568627 

1 

0.0 

2354 

99.8 

85.490196078 

1 

0.0 

2355 

99.8 

90.980392157 

1 

0.0 

2356 

99.9 

96.078431373 

1 

0.0 

2357 

99.9 

98.039215686 

2 

0.1 

2359 

100.0 

Cumulative 

XLOADF  Frequency  Percent  Frequency  Percent 


0.3921568627  2359  100.0  2359  100.0 


98 


Variable 


N 


Mean 


Std  Dev  Minimum  Maximum 


XLOADl 

2359 

3.9325404 

10.6395563 

0.3921569 

98.0392157 

XLOAD4 

2359 

34.9420243 

23.3059572 

0.3921569 

100.0000000 

XLOAD5 

2359 

0.7138286 

1.1494338 

0.3921569 

28.6274510 

XLOAD7 

2359 

0.8830595 

5.1087385 

0.3921569 

98.0392157 

XLOADF 

2359 

0.3921569 

0 

0.3921569 

0.3921569 

HOUR=00 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

95 

1.1351909 

2.5437021 

0.3921569 

21.1764706 

XLOAD4 

95 

21.9855521 

20.5044732 

0.3921569 

92.5490196 

XLOAD5 

95 

0.3962848 

0.0402344 

0.3921569 

0.7843137 

XLOAD7 

95 

0.3962848 

0.0402344 

0.3921569 

0.7843137 

XLOADF 

95 

0.3921569 

0 

0.3921569 

0.3921569 

HOUR=01 


Variable 

N 

Mean 

Std  Dev  Minimum 

Maximum 

XLOADl 

96 

0.8537582 

1.2150467 

0.3921569 

10.5882353 

XLOAD4 

96 

28.0269608 

21.0668687 

0.3921569 

87.4509804 

XLOAD5 

96 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

96 

0.4370915 

0.2119083 

0.3921569 

1.5686275 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 

HOUR=02 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

98 

0.7402961 

0.6939737 

0.3921569 

3.5294118 

XLOAD4 

98 

36.6986795 

21.4577464 

0.3921569 

90.9803922 

XLOAD5 

98 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

98 

0.4161665 

0.1671987 

0.3921569 

1.5686275 

XLOADF 

98 

0.3921569 

0 

0.3921569 

0.3921569 

HOUR=03 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

98 

0.7202881 

0.6388044 

0.3921569 

3.5294118 

XLOAD4 

98 

37.8591437 

20.3488966 

0.3921569 

94.5098039 

XLOAD5 

98 

0.3961585 

0.0396138 

0.3921569 

0.7843137 

XLOAD7 

98 

0.4241697 

0.1751379 

0.3921569 

1.5686275 

XLOADF 

98 

0.3921569 

0 

0.3921569 

0.3921569 

99 


HOUR=04  ~ 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

96 

0.5882353 

0.4407463 

0.3921569 

1.5686275 

XLOAD4 

96 

28.0596405 

16.7210665 

0.3921569 

92.5490196 

XLOAD5 

96 

0.4003268 

0.0563043 

0.3921569 

0.7843137 

XLOAD7 

96 

0.4044118 

0.1200730 

0.3921569 

1.5686275 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 

- HOUR=05  — 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

97 

0.7802709 

0.9205509 

0.3921569 

5.0980392 

XLOAD4 

97 

27.9482515 

16.4354897 

0.3921569 

81.9607843 

XLOAD5 

97 

0.3961997 

0.0398175 

0.3921569 

0.7843137 

XLOAD7 

97 

0.4164140 

0.1364875 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 

- HOl]R=06 - 

Variable  N  Mean  Std  Dev  Minirauni  Maximum 

XLOADl  96  8.6437908  24.9907353  0.3921569  98.0392157 

XLOAD4  96  46.2500000  23.2802642  0.3921569  98.0392157 

XLOAD5  96  0.4656863  0.2500531  0.3921569  1.5686275 

XLOAD7  96  0.4738562  0.3639679  0.3921569  3.5294118 

XLOADF  96  0.3921569  0  0.3921569  0.3921569 


-HOUR=07 - 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

95 

5.6842105 

12.6953393 

0.3921569 

96.0784314 

XLOAD4 

95 

35.9133127 

20.0593473 

0.3921569 

96.0784314 

XLOAD5 

95 

0.6150671 

0.6563351 

0.3921569 

5.0980392 

XLOAD7 

95 

0.5696594 

0.5684862 

0.3921569 

3.5294118 

XLOADF 

95 

0.3921569 

0 

0.3921569 

0.3921569 

- HOUR=08 - 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

98 

7.2589036 

14.7691511 

0.3921569 

87.4509804 

XLOAD4 

98 

43.5174070 

25.5061109 

0.3921569 

96.0784314 

XLOAD5 

98 

1.2404962 

1.8069370 

0.3921569 

8.2352941 

XLOAD7 

98 

1.5726291 

9.8540855 

0.3921569 

98.0392157 

XLOADF 

98 

0.3921569 

0 

0.3921569 

0.3921569 

100 


HOUR=09 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

100 

6.7686275 

11.3621797 

0.3921569 

71.3725490 

XLOAD4 

100 

40.9019608 

23.1422226 

0.3921569 

96.0784314 

XLOAD5 

100 

1.5411765 

3.3117707 

0.3921569 

28.6274510 

XLOAD7 

100 

1.7803922 

9.0230379 

0.3921569 

85.4901961 

XLOADF 

100 

0.3921569 

0 

0.3921569 

0.3921569 

HOUR=10 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

97 

6.5130382 

11.2360179 

0.3921569 

85.4901961 

XLOAD4 

97 

38.8356580 

21.5497878 

1.5686275 

98.0392157 

XLOAD5 

97 

0.9096422 

1.0597708 

0.3921569 

5.0980392 

XLOAD7 

97 

2.6844552 

13.2715963 

0.3921569 

96.0784314 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 

H0IIR=11 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

101 

6.4453504 

11.2357446 

0.3921569 

87.4509804 

XLOAD4 

101 

39.3321685 

22.2867644 

0.3921569 

98.0392157 

XLOAD5 

101 

0.7843137 

0.7145438 

0.3921569 

3.9215686 

XLOAD7 

101 

1.9180742 

10.4043437 

0.3921569 

98.0392157 

XLOADF 

101 

0.3921569 

0 

0.3921569 

0.3921569 

•H0UR=12 - 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

113 

7.5585632 

15.9368336 

0.3921569 

94.5098039 

XLOAD4 

113 

40.5760888 

22.9887743 

5.0980392 

100.0000000 

XLOAD5 

113 

0.9300711 

0.8138600 

0.3921569 

3.5294118 

XLOAD7 

113 

2.8318584 

10.9078404 

0.3921569 

83.9215686 

XLOADF 

113 

0.3921569 

0 

0.3921569 

0.3921569 

- H0UR=13 - 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

102 

8.6543637 

14.9578756 

0.3921569 

85.4901961 

XLOAD4 

102 

46.1707036 

22.7281500 

1.5686275 

96.0784314 

XLOAD5 

102 

1.2379854 

1.2629150 

0.3921569 

6.2745098 

XLOAD7 

102 

1.3341023 

3.8098071 

0.3921569 

30.1960784 

XLOADF 

102 

0.3921569 

0 

0.3921569 

0.3921569 

101 


- HOl]R=14 - 

Variable  N  Mean  Std  Dev  Nfinimum  Maximum 


XLOADl  100  7.4235294  11.9424423  0.3921569  71.3725490 

XLOAD4  100  48.9764706  24.2141660  1.5686275  96.0784314 

XLOAD5  100  1.4784314  2.2266601  0.3921569  14.9019608 

XLOAD7  100  0.5843137  0.3999814  0.3921569  2.3529412 

XLOADF  100  0.3921569  0  0.3921569  0.3921569 


HOUR=15 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximmn 

XLOADl 

99 

9.4236482 

16.3475515 

0.3921569 

94.5098039 

XLOAD4 

99 

44.7969895 

21.5666504 

0.3921569 

94.5098039 

XLOAD5 

99 

1.3586849 

1.4406728 

0.3921569 

8.6274510 

XLOAD7 

99 

0.7803525 

0.7250411 

0.3921569 

3.5294118 

XLOADF 

99 

0.3921569 

0 

0.3921569 

0.3921569 

HOUR=16 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

101 

5.5523199 

9.2353953 

0.3921569 

47.8431373 

XLOAD4 

101 

37.5965832 

24.2683107 

0.3921569 

96.0784314 

XLOAD5 

101 

0.9318579 

1.2436400 

0.3921569 

8.6274510 

XLOAD7 

101 

0.6328868 

0.4330459 

0.3921569 

1.9607843 

XLOADF 

101 

0.3921569 

0 

0.3921569 

0.3921569 

-HOUR=17 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

99 

1.9172113 

5.3976330 

0.3921569 

49.8039216 

XLOAD4 

99 

34.6326005 

23.4261203 

0.3921569 

98.0392157 

XLOAD5 

99 

0.5228758 

0.5042017 

0.3921569 

3.5294118 

XLOAD7 

99 

0.5466429 

0.8566451 

0.3921569 

8.6274510 

XLOADF 

99 

0.3921569 

0 

0.3921569 

0.3921569 

HOUR=18 - 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

96 

1.2050654 

1.4752878 

0.3921569 

7.0588235 

XLOAD4 

96 

33.4395425 

23.1331251 

0.3921569 

92.5490196 

XLOAD5 

96 

0.5106209 

0.5093108 

0.3921569 

4.7058824 

XLOAD7 

96 

0.4289216 

0.2351436 

0.3921569 

2.3529412 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 

102 


H0UR=19 


Variable 

N 

Mean 

StdDev 

Minimum 

Maximum 

XLOADl 

95 

1.6676987 

6.9989975 

0.3921569 

67.8431373 

XLOAD4 

95 

30.8400413 

23.5487972 

0.3921569 

92.5490196 

XLOAD5 

95 

0.4293086 

0.1723069 

0.3921569 

1.5686275 

XLOAD7 

95 

0.4458204 

0.2467688 

0.3921569 

1.9607843 

XLOADF 

95 

0.3921569 

0 

0.3921569 

0.3921569 

-HOUR=20 


Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

96 

0.9477124 

1.7104766 

0.3921569 

15.6862745 

XLOAD4 

96 

26.7687908 

21.3291325 

0.3921569 

92.5490196 

XLOAD5 

96 

0.4330065 

0.2574952 

0.3921569 

2.7450980 

XLOAD7 

96 

0.4207516 

0.1730062 

0.3921569 

1.5686275 

XLOADF 

96 

0.3921569 

0 

0.3921569 

0.3921569 

tiniTD— 

Vari^le 

N 

Mean 

StdDev 

Minimum 

Maximum 

XLOADl 

97 

0.7196281 

0.6878609 

0.3921569 

3.5294118 

XLOAD4 

97 

25.9874672 

21.1939769 

0.3921569 

92.5490196 

XLOAD5 

97 

0.4244997 

0.3185400 

0.3921569 

3.5294118 

XLOAD7 

97 

0.4204568 

0.1721272 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 

XiniTD— 

Variable 

N 

Mean 

StdDev 

Minimum 

Maximum 

XLOADl 

97 

0.7236709 

0.7643291 

0.3921569 

5.0980392 

XLOAD4 

97 

21.9041844 

21.2156946 

0.3921569 

94.5098039 

XLOAD5 

97 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

97 

0.4164140 

0.1680492 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 

Variable 

N 

Mean 

Std  Dev 

Minimum 

Maximum 

XLOADl 

97 

1.0632707 

1.1047861 

0.3921569 

5.0980392 

XLOAD4 

97 

18.3828583 

20.1126408 

0.3921569 

76.4705882 

XLOAD5 

97 

0.3921569 

0 

0.3921569 

0.3921569 

XLOAD7 

97 

0.4244997 

0.1760171 

0.3921569 

1.5686275 

XLOADF 

97 

0.3921569 

0 

0.3921569 

0.3921569 
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APPENDIX  E.  CURRENT  TECHNOLOGIES 


Chapter  Vn  mentioned  some  of  the  services  that  are  currently  offered  by  local  and 
national  service  providers.  This  Appendix  introduces  a  few  of  those  technologies,  and  is 
intended  to  familiarize  the  reader  with  a  few  of  the  alternative  solutions  currently  available 
in  the  marketplace.  As  mentioned  in  Chapter  Vn,  those  organizations  that  fall  behind  the 
technology  curve  will  not  only  loose  their  competitive  advantage,  but  the  productivity, 
efficiency,  and  effectiveness  of  their  organizations  will  also  be  in  jeopardy.  The  pros  and 
cons  of  these  technologies  are  varied.  Be  sure  to  investigate  all  available  alternatives 
thoroughly  before  investing  in  any  one  particular  service. 

A.  INTEGRATED  SERVICES  DIGITAL  NETWORK  (ISDN) 

ISDN  is  described  as  a  high  speed,  low  cost,  all  digital  dialup  telephone  service 
delivered  to  both  businesses  and  homes  over  standard  copper  wires.  ISDN  maximizes  the 
transmission  capability  of  existing  copper  wires,  allowing  the  simultaneous  transmission  of 
voice,  data,  and  video  over  a  single  twisted  pair  connection  [Ref  27].  This  technology 
was  thought  to  be  the  great,  new,  all  digital  technology  that  would  replace  the  plain  old 
telephone  system  (POTS). 

The  basic  unit  of  switching  for  ISDN  is  a  64-Kbps  B-charmel.  A  separate  16-Kbps 
D-channel  is  provided  as  a  control  channel.  The  main  problem  with  ISDN’s  B-channel  is 
that  it  is  becoming  increasingly  inadequate  for  many  subscribers  who  are  using  high- 
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powered  workstations  and  graphics  and  image  processing  applications  [Ref.  28],  Some  of 
the  characteristics  of  ISDN  include:  [Ref  29] 


•  Fast  connection  time. 

•  High  bandwidth. 

•  End-to-end  digital  connection. 

•  Supports  voice,  data,  and  video  on  a  single  line. 

•  May  be  circuit-switched,  packet-switched,  or  semi-permanently  connected. 

•  Physically,  it  is  a  twisted  pair  wire. 

•  Available  in  two  rates: 

1 .  Basic  Rate  Interface  (BRI)  -  2B  +  D  for  144  Kbps. 

2.  Primary  Rate  Interface  (PM)  -  23B  +  D  for  1 .536  Mbps. 

Those  organizations  looking  to  support  a  WWW  server  and  MPEG  video  should  look  into 
the  ISDN  PRI  line,  which  has  a  rate  similar  a  T-1  link.  The  ISDN  PRI  link  is  reportedly 
less  expensive  than  a  T-1,  but  for  accurate  pricing  information,  interested  parties  should 
consult  with  their  local  telecommunications  providers. 


B.  FRAME  RELAY 

The  frame  relay  standard  defines  an  interface  between  a  user  device  and  a  network. 
It  is  a  streamlined  version  of  X.25  packet  switching,  designed  to  increase  speed  by 
drastically  reducing  the  amount  of  processing  time  in  data  transfer  mode.  Frame  relay 
eliminates  the  Level-3  processing  (the  packet  level  or  Network  Layer  in  X.25),  and 
discards  frame  sequencing  and  error  recovery  at  the  frame  level  (Layer  2  in  the  OSI 
model).  [Ref  30] 

Frames  are  received  by  the  network  over  a  frame  relay  interface  and  forwarded 
hop-by-hop  from  source  node  to  destination  node.  This  operation  is  very  similar  to  the 
forwarding  of  packets  in  virtual  circuit-based  packet  switching  networks.  The  main 


difference  is  that  sequence  number  checking  and  retransmissions  due  to  errors  do  not  get 
retransmitted  at  any  step  along  the  way.  Frames  with  errors  (detected  by  frame  checking 
sequences)  are  simply  discarded  .  This  hop-by-hop  forwarding  of  frames  is  called  frame 
relay.  The  main  advantage  of  frame  relay  is  the  high  speed  physical  medium  (interface) 
with  statistical  multiplexing  to  combine  multiple  channels.  [Ref  30] 

Frame  relay  transfers  information  in  variable  length  packets  (frames),  and  can 
contain  thousands  of  b)1:es  of  data.  The  amount  of  overhead  needed  to  transmit  data 
through  frame  relay  is  inherently  lower  than  the  overhead  required  for  Asynchronous 
Transfer  Mode  (ATM),  which  is  discussed  in  the  next  section.  Some  of  the  characteristics 
of  ISDN  include;  [Ref  31] 

•  Requires  five  bytes  of  header  information  for  transmission  through  network. 

•  Percentage  of  bandwidth  devoted  to  overhead  varies  according  to  the  size  of 
the  frame. 

•  Delay  characteristics  make  it  less  appropriate  for  carrying  real-time  multimedia 
applications  such  as  video  teleconferencing. 

•  Operates  at  very  high  speeds,  accommodating  large  amounts  of  data  with  very 
low  delay. 

•  Provides  highly  efficient  resource  sharing  by  supporting  many  virtual  channels 
over  a  high  speed  line. 

•  Typical  line  sizes  range  from  56-Kbps  to  T-l/E-1  (1.544/2.048  Mbps). 

•  Unpredictable  due  to  the  variable  length  packets,  which  cause  confusion  for  the 
switches  and  transmission  equipment;  they  do  not  know  exactly  where  each 
cell  ends  and  the  next  one  begins. 

•  Similar  to  X.25,  except  all  circuits  are  permanently  assigned. 

•  Relies  on  the  customer  equipment  to  perform  end-to-end  error  correction. 

Visit  URL  http;//www.dcnet.com/notes/framerly.html  for  a  very  good  overview  of  Frame 
Relay  terms,  or  try  URL  http://www.kalpana.com/warp/public/732/Frame/fratm_wp.htm 
to  compare  Frame  Relay  and  ATM  WAN  technologies. 
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C  ASYNCHRONOUS  TRANSFER  MODE  (ATM) 

ATM  is  an  internationally  accepted  high-performance  multiplexing  and  switching 
technology  that  is  touted  to  be  the  multi-media  communications  technology  that  will  take 
us  into  the  next  generation.  ATM  protocols  are  designed  to  handle  isochronous  (time 
critical)  data  such  as  video  and  audio,  along  with  the  more  traditional  data 
communications  between  computers.  [Ref  32] 

The  interest  in  ATM  has  grown  out  of  the  need  for  a  worldwide  standard  to  allow 
interoperability  of  information.  The  goal  of  ATM  is  to  provide  one  international  standard. 
Kstorically,  there  have  been  several  methods  used  for  the  transmission  of  information 
between  users.  ATM  is  a  method  that  can  be  used  interchangeably  for  all  traflBc  types, 
regardless  of  whether  the  data  is  transmitted  over  a  LAN,  WAN,  or  MAN.  The  goal  is  to 
close  the  gap  between  the  various  network  types,  making  the  transmission  of  data  between 
them  seamless  to  the  end  users  based  on  one  standard  system  -  ATM.  [Ref  33] 

The  following  set  of  User-Network  Interfaces  has  been  prescribed  by  the  ATM 
Forum:  [Ref  29] 

•  DS-3  (45  Mbps). 

•  OC-1  (51  Mbps). 

•  TAXI  (100  Mbps  and  140  Mbps  over  multimode  fiber). 

•  OC3c  (155  Mbps). 

•  OC-48  (2.488  Gbps). 

Some  of  the  characteristics  of  ATM  include:  [Ref.  3 1] 

•  Fixed  length  packets  (cells). 

-  payload  (48  bytes)  carries  actual  information. 

-  header  (5  bytes)  is  the  addressing  mechanism. 


•  Smaller,  fixed-length  cells  results  in  much  higher  overhead  than  Frame  Relay, 
but  offers  two  advantages  over  Frame  Relay: 

1.  Speed  -  easier  to  process,  since  the  switching  and  transmission 
equipment  know  exactly  where  each  cell  ends  and  the  next  one  begins. 

2.  Small  cells  with  a  predictable  transmission  delay  allow  for  interleaving 
cells  that  carry  delay-sensitive  traffic,  such  as  interactive  video  and 
voice  along  with  data  cells. 

•  Layered  architecture  allows  voice,  video,  and  data  to  be  mixed  over  the 
network. 

The  layered  architecture  mentioned  above  has  three  lower  layers  that  have  been 
established  to  implement  the  features  of  ATM:  [Ref  32] 

•  The  Adaptation  Layer  -  assures  the  appropriate  service  characteristics  and 
divides  all  types  of  data  into  the  48  byte  payload  that  will  make  up  the  ATM 
cell. 

•  The  ATM  Layer  -  takes  the  data  that  is  to  be  sent  and  adds  the  5-byte  header 
information  that  assures  the  cell  is  sent  along  the  correct  connection. 

•  The  Physical  Layer  -  defines  the  electrical  characteristics  and  network 
interfaces.  This  layer  “puts  the  bits  on  the  wire”. ^ 

For  more  information  regarding  the  ATM  Forum,  or  for  more  technology,  architecture,  or 

benefits  related  information  on  ATM,  try  the  following  URLs,  respectively: 

http://www.atmforum.com/atmforum/atm_introduction.html 

http://www.npac.syr.edu/users/dpk/ATM_Knowledgebase/ATM_technology.html. 


D.  ASYMMETRICAL  DIGITAL  SUBSCRIBER  LINE  (ADSL) 

1.  General  Information  and  Features 

ADSL  provides  the  highest  access  speed  possible  to  the  internet  today  over  a 
single  copper  pair.  This  technology  reportedly  achieves  near  instantaneous  home  page 
downloads  and  file  transfers  fi'om  the  internet.  ADSL  allows  users,  whether  in  the 

*  ATM  is  not  tied  to  a  q)ecific  of  physical  transport. 
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business  or  residential  environment,  to  access  the  internet  at  T-1  speeds  over  traditional 
phone  lines.  At  T-1  speeds,  the  actual  throughput  can  be  up  to  50  times  faster  than  the 
typical  28.8  modem,  or  12  times  faster  than  a  128-Kbps  ISDN  coimection.  [Ref  34] 

Two  companies,  Westell  and  Microsoft,  are  working  together  on  this  new 
transmission  technology.  Additionally,  GTE  Telephone  Operations,  Irving,  Texas,  and  US 
West  Interprise  Networking  Services,  Denver,  Colorado,  are  implementing  or  expanding 
their  market  trials  of  ADSL  technology.  According  to  GTE,  ADSL  is  capable  of 
providing  up  to  6-Mbps  downstream  (from  the  network  to  the  user)  and  up  to  640-Kbps 
upstream  (from  the  user  to  the  network),  all  over  the  existing  telephone  lines.  At  4-Mbps, 
200  pages  of  text  can  be  downloaded  in  less  than  one  second,  and  a  typical  WWW  page 
with  graphics  can  be  downloaded  in  less  than  one-tenth  of  a  second.  ADSL  also  offers  the 
user  the  opportunity  to  receive  data  and  use  their  telephone,  fax  machine,  or  modem 
simultaneously.  [Ref  35] 

This  new  technology  is  currently  undergoing  a  six-month  trial  period,  designed  to 
test  the  high  speed  communications  capabilities  of  ADSL  over  the  existing  phone  lines. 
Exact  prices  for  this  technology  are  expected  to  be  available  at  the  end  of  the  year.  For 
more  information  regarding  uses  and  applications  of  ADSL,  try  visiting  the  ADSL  Forum 
at  URL  http://www.adsl.com/adsl/home_page.html,  or  for  more  information  regarding  the 
trial  test  period  visit  GTE  at  URL  http://wcn.gte.com/adsl. 
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2.  ADSL  Enhances  Healthcare 


The  healthcare  field  can  benefit  fi'om  the  ADSL  technology  in  several  ways.  This 
section  outlines  a  few  specific  areas  that  are  affected  [Ref.  34]. 

(L  TelemetUcine 

This  live,  two-way,  interactive  video  communication  allows  patients  to 
consult  physicians  at  remote  locations  for  specialty  care  not  available  in  the  patient’s  area. 
ADSL  can  deliver  this  extensive  service  at  fi’action  of  the  cost  of  fiber  based  systems,  and 
provides  the  versatility  of  simultaneous  records  management,  image,  and  file  transfer 
capabilities. 


b.  Teleradiology 

Whether  you  are  working  in  a  PC  or  Unix  based  environment,  ADSL  can 
deliver  biomedical  images  of  any  mode,  and  size,  fi'om  point-to-point  in  seconds.  Remote- 
primary  diagnoses  are  now  possible  in  real  time  with  high-quality  image  resolution  that  is 
not  degraded  by  the  ADSL  system. 

c.  On-Line  Medical  Research  and  Internet  Access 

The  national  Library  of  Medicine  estimates  that  there  are  over  4,000 
medical  libraries  within  the  U.S.,  half  of  which  are  accessible  throughout  the  internet. 
Many  of  these  libraries  employ  medical  literature  and  retrieval  systems  (MEDLARS)  for 
on-line  information  services.  Physicians  are  increasingly  turning  to  these  on-line  medical 
data  uses  to  diagnose  difficult  cases,  track  new  developments,  lower  costs,  and  shorten 
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hospital  stays.  ADSL  can  provide  a  high  speed  link  to  these  services  to  improve  overall 
quality  of  care. 


d.  ADSL  Healthcare  Advantages 

Some  of  the  technological  advantages  that  ADSL  offers  the  healthcare  field 


include; 

•  Faster  response  and  delivery  time  in  case  of  emergency  care  situations. 

•  Improved  overall  patient  care  through  resource  sharing  and  high-speed  data 
access. 

•  Flexible,  transparent  point-to-point  access  increases  savings  for  healthcare 
systems  integration’s. 
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Attn:  Management  Information  Department 
6000  W.  Highway  98 
Bldg.  2268,  Rm.  2023 
Pensacola,  FL  32512-0003 
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8.  Commanding  Officer . 2 

Naval  Medical  Information  Management  Center 
8901  Wsconsin  Ave.,  Bldg.  27 
Bethesda,  MD  20889 


9.  Dr.  Suresh  Sridhar,  Code  SM/Sr . 1 

Naval  Postgraduate  School 

Monterey,  CA  93 943-5 101 

10.  Helen  Davis,  Code  51 . 1 

Naval  Postgraduate  School 

Monterey,  CA  93 943-5 101 

11.  LT  K.  L.  Trovini . 1 

33969  North  Lake  Road 

Gages  Lake,  IL  60030 

12.  Naval  Medical  Information  Management  Center . 1 

Norfolk  Detachment 

Attn:  Leslie  Parks 

6500  Hampton  Blvd.,  Bldg.  C 

Norfolk,  VA  23508 


13 .  Naval  Medical  Information  Management  Center . 1 

San  Diego  Detachment 
Attn:  LCDR  C.  Eichling 
3666  Kearny  Villa  Road 
3rd  Floor,  Rm.  345 
San  Diego,  CA  92123-1949 


14.  Rex  Buddenberg,  Code  SM/Bu . 1 

Naval  Postgraduate  School 

Monterey,  CA  93943-5101 

1 5 .  Tricare  Region  2 :  Portsmouth  Naval  Hospital . 1 

Attn:  G.  Lenentine 

5425  Robinson  Road 
Suite  203 

Norfolk,  VA  23513 
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16.  Tricare  Region  9:  Tricare  Southern  California 
Attn:  LTCOL  A.  W.  Powell 
34800  Bob  Wilson  Drive 
Bldg.  6-4 

San  Diego,  CA  92134-5000 
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